LCR Updater wird nach reboot der Fritz!Box nicht gestartet :-(

[tchelovek]

Möglicherweise wird das schon diskutiert und ich hab's nicht gefunden.

Jedenfalls stelle ich bei meiner Fritz!Box 7390 (FRITZ!OS 05.58-26237 BETA, Telefon-Sparbuch LCR Updater V1.50.33 lizenzierte Version (27.04.2013)) neuerdings fest, daß einerseits die Anrufliste wieder korrekt dargestellt wird , andererseits nach einem Reboot ( Firmware-Update ) der LCR Daemon nicht läuft :-( .

Ich behelfe mich im Moment damit, daß ich die debug.cfg in ein shell skript eingebaut habe, welches ich bei Bedarf manuell starte.

Ob der Daemon läuft, sieht man am Anmeldebildschirm der Fritz!box, falls ja, ist ein Link zum LCR vorhanden.

Wer's nicht merkt, sieht es spätestens bei Erhalt der Telefonrechnung.

Vielleicht kann Harald da mal 'reinschauen ?

 

[Willly]

Hier ohne Probleme, Daemon läuft.

 

[TelefonSparbuch]

Was ist noch installiert, wie Fritzload oder andere "Programm-Pakete"?

 

[tchelovek]

Was ist noch installiert, wie Fritzload oder andere "Programm-Pakete"?

Außer Telefonsparbuch verwende ich noch FHEM 5.4 (nicht die chroot version), das wird allerdings in der debug.cfg erst _nach_ LCR aufgerufen. An Hardware gibt es einen USB Flash-Specher (direkt angesteckt) und drei USB Transmitter ( über stromversorgten HUB ) für FHEM.

Daneben verwende ich 3 Powerline Adapter und zwei Fritz!DECT - Steckdosen.

 

[TelefonSparbuch]

Wurde der LCR Daemon gestartet und dann in der Ausführung (Meldungsseite) beendet oder wurde er gar nicht gestartet?

 

[tchelovek]

Das kann ich so nicht sagen, vermutlich geht irgendwas beim Start schief, da ja die debug.cfg abgearbeitet wird.

Wie könnte ich das feststellen ?

 

[TelefonSparbuch]

Der LCR Daemon schreibt die Logs in die Meldungsseite. Falls die nach dem Start leer bleibt wäre der Daemon wohl nicht gestartet worden, steht was drinnen wurde er in der Ausführung abgebrochen (kill oder sonstiges, was evtl. auch ein anderer Prozess auslösen könnte...)

 

[tchelovek]

Der LCR Daemon schreibt die Logs in die Meldungsseite.

Jetzt steh' ich ein wenig auf dem Schlauch. Die Meldungsseite kann ich doch nur anzeigen, wenn der Daemon läuft, oder ?

Nach einem Reboot, ob mit oder ohne FW-Update, erreiche ich den LCR ja nicht mehr, da das Link in der Fritz!Box Anmeldeseite nicht angezeigt wird.

Anmelden mit Telnet und ps | grep lcr zeigt ebenfalls nichts.

Möglicherweise benötigt der LCR etwas von der Box, was zum planmäßigen Start noch nicht vorhanden ist ?

Wenn ich den LCR-Inhalt der debug.cfg in ein Skript packe, und dieses aufrufe startet der LCR wie erwartet.

 

[TelefonSparbuch]

Der LCR Updater trägt in die debug.cfg das Installationsscript ein, welches den LCR Updater bei jedem Neustart einrichtet. Entsprechend sollten auch die Seiteninhalte des LCR Updaters funktionieren. Zusätzlich wird zum Schluss der LCR Daemon (Hintergrundprozess) gestartet, welcher die stündlichen Tarifupdates ausführt.

Das Installationslog sieht man auch unter http://fritz.box/html/lcr.html (welches beim erstmaligen Aufruf der Wahltabelle mit dieser überschrieben wird).

Es ist halt die Frage, ob der LCR Updater bei einer normalen Installation auch gestartet wird und im späteren Verlauf (anderes Tool) zwangsweise beendet wird, oder gar nicht erst bei der Installation gestartet wird.

 

[tchelovek]

So, jetzt habe ich einen Neustart durchgeführt, LCR Link ist nicht vorhanden, ps | grep lcr zeigt nichts, die Seite unter http://fritz.box/html/lcr.html hänge ich unten an.

Dies ist die Wahltabellenseite.
Waehrend der Installation koennen Sie die aktuelle LCR Updater Installations-Log einsehen (Browserinhalt aktualisieren mittels 'F5' Taste).
Nach der Installation wird diese Seite durch eine vorhandene Wahltabelle ersetzt (sofern eine LCR Tabelle berechnet wurde - was vorraussetzt, dass eine LCR Konfiguration vorhanden ist)

Installationsverlauf:
01.01.70 01:00:51 Starte LCR Updater Installer V1.50.33 lizenzierte Version (27.04.2013)
01.01.70 01:00:51 Warte mit Einrichtung des LCR Updaters, bis Internetverbindung verfuegbar
- ping lcr.telefonsparbuch.de
26.08.13 12:55:08 Internetverbindung verfuegbar
26.08.13 12:55:24 Lade LCR Updater Programmdateien von lcr.telefonsparbuch.de
26.08.13 12:55:25 Programmdateien erhalten
26.08.13 12:55:25 TAR-Archiv MD5-Pruefsumme korrekt
26.08.13 12:55:25 Entpacke LCR Updater TAR-Archiv
26.08.13 12:55:26 Vollstaendige Installation
26.08.13 12:55:26 LED ON
26.08.13 12:55:26 mkdir -pm 777 /var/tmp (OK)
26.08.13 12:55:26 mkdir -pm 777 /var/tmp/tsb (OK)
26.08.13 12:55:26 mkdir -pm 777 /var/tmp/tsb/etc (OK)
26.08.13 12:55:26 mkdir -pm 777 /var/tmp/tsb/var (OK)
26.08.13 12:55:26 mkdir -pm 777 /var/tmp/tsb/lib (OK)
26.08.13 12:55:26 mkdir -pm 777 /var/tmp/tsb/lib/www (OK)
26.08.13 12:55:26 mkdir -pm 777 /var/tmp/tsb/var/sessions (OK)
26.08.13 12:55:26 mkdir -pm 777 /var/tmp/tsb/var/www (OK)
26.08.13 12:55:27 mkdir -pm 777 /var/tmp/tsb/var/www/cgi-bin (OK)
26.08.13 12:55:27 mkdir -pm 777 /var/tmp/tsb/var/www/cgi-bin/tsb (OK)
26.08.13 12:55:27 mkdir -pm 777 /var/tmp/tsb/var/orgwww (OK)
26.08.13 12:55:27 rootDir: /usr/www/avm
26.08.13 12:55:27 Richte Verzeichnisstruktur ein
26.08.13 12:55:27 cp /usr/www/avm/apple-touch-icon.png /var/tmp/tsb/var/www/apple-touch-icon.png (OK)
26.08.13 12:55:27 mkdir -pm 777 /var/tmp/tsb/var/orgwww/assis (OK)
26.08.13 12:55:27 mount -o bind /usr/www/avm/assis /var/tmp/tsb/var/orgwww/assis (OK)
26.08.13 12:55:27 cp /usr/www/avm/capture.lua /var/tmp/tsb/var/www/capture.lua (OK)
26.08.13 12:55:27 ln -s /usr/www/cgi-bin/capture_notimeout /var/tmp/tsb/var/www/cgi-bin/capture_notimeout (OK)
26.08.13 12:55:27 ln -s /usr/www/cgi-bin/firmwarecfg /var/tmp/tsb/var/www/cgi-bin/firmwarecfg (OK)
26.08.13 12:55:28 ln -s /usr/www/cgi-bin/luacgi /var/tmp/tsb/var/www/cgi-bin/luacgi (OK)
26.08.13 12:55:28 ln -s /usr/www/cgi-bin/luacgi /var/tmp/tsb/var/www/cgi-bin/luacgi_notimeout (OK)
26.08.13 12:55:28 ln -s /usr/www/cgi-bin/system_status /var/tmp/tsb/var/www/cgi-bin/system_status (OK)
26.08.13 12:55:28 ln -s /usr/www/cgi-bin/tr064cgi /var/tmp/tsb/var/www/cgi-bin/tr064cgi (OK)
26.08.13 12:55:28 ln -s /usr/www/cgi-bin/webcm /var/tmp/tsb/var/www/cgi-bin/webcm (OK)
26.08.13 12:55:28 ln -s /usr/www/cgi-bin/webtrace /var/tmp/tsb/var/www/cgi-bin/webtrace (OK)
26.08.13 12:55:28 ln -s /usr/www/cgi-bin/webtrace /var/tmp/tsb/var/www/cgi-bin/webtrace_notimeout (OK)
26.08.13 12:55:29 ln -s /var/tmp/crossdomain.xml /var/tmp/tsb/var/www/crossdomain.xml (OK)
26.08.13 12:55:29 LCR Updater Einrichtung nicht vollstaendig abgeschlossen oder es sind Fehler aufgetreten

 

[TelefonSparbuch]

Meldungsseite (LCR Updater: Meldungen)? Und steht noch was unter Meldungen/Systeminformationen: Signal- und Fehlermeldungen vom LCR Daemon

 

[tchelovek]

Meldungsseite (LCR Updater: Meldungen)? Und steht noch was unter Meldungen/Systeminformationen: Signal- und Fehlermeldungen vom LCR Daemon

Wo finde ich das, wenn der LCR nicht läuft ? Ich dachte Du meinst die http://fritz.box/html/lcr.html .

 

[TelefonSparbuch]

Ich werde mal die Laborversion testen :gruebel:

 

[tchelovek]

Hallo Harald,

ich bin der Sache etwas näher gekommen.

Wenn der Aufruf für FHEM in der debug.cfg im Anschluß an den LCR-Eintrag steht, wird zwar FHEM gestartet, aber LCR bleibt irgendwo hängen.

Stelle ich den Aufruf für FHEM

/var/InternerSpeicher/fhem/startfhem

voran, funktioniert alles wie erwartet.

In der debug.cfg steht in Zeile 11

md5sum, m

Das gehört da meines Erachtens nicht hin, da es lediglich eine Fehlermeldung verursacht, aber sonst keine Fehlfunktion auftritt.

 

[TelefonSparbuch]

Der LCR Daemon bleibt nicht hängen, sondern er wird während der Ausführung gekilled, ohne das ein Signal vom Prozess noch verarbeitet werden kann. Ich kann das Verhalten zwar reproduzieren, aber den eigentlichen Grund habe ich bislang nicht finden können.

 

[tchelovek]

Na immerhin kannst Du es reproduzieren, ich dachte schon ich bin der Einzige dem das passiert.

Also entweder gibt es außer mir niemanden der TSB _und_ FHEM einsetzt, oder die merken nicht, daß ihr TSB nicht läuft. Neustarts der Fritz!Box hat man beim Experimentieren mit FHEM häufiger.

Ich denke, wenn Du bei der Installation den TSB-relevanten Teil _hinter_ den vorhandenen Einträgen in der debug.cfg einfügst, hast Du das Problem zwar nicht gelöst, aber elegant umgangen.

Noch eins, beim Testen habe ich jetzt mal die Versionen 1.50.34 und 1.50.35 ausprobiert, bei beiden wird die Anrufliste nicht angezeigt. Das geht bei mir nur mit 1.50.33

 

[TelefonSparbuch]

Die Ursache ist das SIGHUP nicht als Signal abgefangen wurde. Wird der Deamon mit nohup gestartet sollte es auch erst gar nicht zu dem Signal kommen. In den älteren Firmwares gab es diesbezüglich nie ein Problem, ob es nohup in diesen Busybox Versionen schon gab muss ich noch verifizieren.

Welche Firmware ist bei Dir installiert? Fehm belässt scheinbar die installierte Firmware und richtet nur Fehm zusätzlich im Flash der 7390 ein...

 

[tchelovek]

Fritz!Box 7390 (FRITZ!OS 05.58-26237 BETA, Telefon-Sparbuch LCR Updater V1.50.33 lizenzierte Version (27.04.2013))

war installiert als mir das Problem auffiel, siehe erste Meldung. Inzwischen verwende ich

FRITZ!OS 05.59-26553 BETA, LCR Updater V1.50.33 und FHEM 5.5 ( nicht die AVM - Version !! Image-Datei von fhem.de )

Seit ich die debug.cfg so umgebaut habe, daß zuerst FHEM, dann TSB gestartet wird, habe ich das Problem nicht mehr, wie bereits erwähnt.

Was das SIGHUP anlangt, verstehe ich den Zusammenhang nicht so ganz. SIGHUP wird m.E. erzeugt wenn ein Prozess beendet wird, damit die von ihm gestarteten Tochterprozesse auch beendet werden. Das sollte aber nicht davon abhängig sein, ob vorher oder nachher ein anderes Programm aufgerufen wird.

Wenn ich, nach dem Hochfahren der Fritz!Box, den LCR Updater manuell starte (debug.cfg in ein shell skript umgebaut), passiert das ja auch nicht.