[Gelöst] Callmonitor führt zum Dauerreboot seit der Firmwareversion >7

[hermann72pb]

Wie bereits dort beim OpenVPN-Thread berichtet, kann callmonitor in FREETZ seit der Frirmwareversion >7 zu einem Dauerreboot der Box führen. Das Verhalten wurde bei mir auf einer 7490 mit ReplaceKernel beobachtet. Über ein ähnliches Verhalten wurde bei einer 6590 hier ebenfalls berichtet.
In meinem Fall "lebt" die Box etwa 3-4 Minuten, bis sie mit einem WatchDog-Fehler (s. hier) rebootet. Da ich dropbear im Image habe, kann ich etwa nach 1,5 Minuten eine SSH-Verbindung mit der Box aufbauen und habe dann noch etwa 2 Minuten zur Ursachenanalyse bzw. dafür, um auf eine Schattenkopie der alten Firmware umzuschalten.
ps auf meiner 7490 ergibt Folgendes (nur Ausschnitt):

4752 root      1356 S    {rc.callmonitor} /bin/ash /etc/init.d/rc.callmonitor
 4798 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook init
 4816 root      1348 S    {sipnames} /bin/ash /mod/pkg/callmonitor/usr/lib/callmonitor/sipnames
 4829 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4840 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4842 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4843 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4846 root      1392 S    {busybox} cat
 4847 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4848 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists
[email protected]
 4849 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists [email protected]
 4850 root      1472 S    {phonebook} /bin/ash /usr/bin/phonebook --local exists [email protected]
 4851 root      1344 S    {busybox} sed -n -e  /keine Tarife gespeichert/ { s/.*/NA:/; p; q } s/^.*zur Rufnummer[^[]*\[\([^]]*\)\].*$/\1/ t found b :found  s
 4854 root      1404 S    {busybox} wget -U callmonitor/98d3ccce65 http://www.billiger-telefonieren.de/vorwahlrechner/?num=000ZENSIERT00000000000 -q -O -

Wie man erkennen kann, ist rc.callmonitor samt diverser phonebook-Prozesse dort kräftig unterwegs und bleibt anscheinend auch so, bis der WatchDog vom ctlmgr zuschlägt.
Das Deaktivieren aller Optionen im callmonitor-WebIF führt nicht zum Erfolg: callmonitor wird trotzdem beim Booten initialisiert und es kommt dabei zum Aufhängen.
Abhilfe schafft in diesem Fall das killen vom Prozess 4752. Zusätzlich hatte ich dann einige von "phonebooks" und "sipnames" gekillt, trägt aber wahrscheinlich der Sache nicht bei.
Nach dem Killen von rc.callmonitor scheinen rc.mod und rc.S weiterzulaufen. Im FREETZ-WebIF erscheinen dann endlich die restlichen Pakete, die erst nach callmonitor initialisiert werden. Die Box läuft danach stabil weiter.
Interessanterweise lässt sich callmonitor danach sauber per WebIF als Dienst starten. rc.callmonitor lässt sich sogar ausführen:

root@fritzbox:/var/mod/root# sh -x /etc/init.d/rc.callmonitor
+ readonly APPLET=rc.callmonitor
+ . /mod/etc/default.callmonitor/system.cfg
+ CALLMONITOR_PATH=/sbin:/bin:/usr/sbin:/usr/bin:/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin
+ CALLMONITOR_ROOT=/mod/pkg/callmonitor
+ CALLMONITOR_TMPDIR=/tmp
+ CALLMONITOR_USERCFG=/mod/etc/conf/callmonitor.cfg
+ flash=/tmp/flash
+ CALLMONITOR_FIFO=/var/run/callmonitor/fifo
+ CALLMONITOR_RULES=/tmp/flash/callmonitor/listeners-1
+ CALLMONITOR_PERSISTENT=/tmp/flash/callmonitor/callers
+ CALLMONITOR_TRANSIENT=/var/cache/phonebook/callers
+ CALLMONITOR_DUMPDIR=/var/lib/callmonitor/trace
+ CALLMONITOR_DOC_URL=http://trac.freetz.org/wiki/packages/callmonitor
+ CALLMONITOR_FORUM_URL=http://www.ip-phone-forum.de/showthread.php?t=191723
+ CALLMONITOR_REVERSE_USERDEF=/tmp/flash/callmonitor/reverse-userdef
+ CALLMONITOR_LIBDIR=/mod/pkg/callmonitor/usr/lib/callmonitor
+ CALLMONITOR_REVERSE_CFG=/mod/pkg/callmonitor/usr/lib/callmonitor/reverse/provider.cfg
+ unset -v flash
+ . /mod/pkg/callmonitor/usr/lib/callmonitor/config.sh
+ [ -r /mod/etc/conf/callmonitor.cfg ]
+ . /mod/etc/conf/callmonitor.cfg
+ export CALLMONITOR_AREA_PROVIDER=billiger
+ export CALLMONITOR_DEBUG=yes
+ export CALLMONITOR_DUMP=no
+ export CALLMONITOR_ENABLED=no
+ export CALLMONITOR_EXPERT=yes
+ export CALLMONITOR_MON_HOST=127.0.0.1
+ export CALLMONITOR_MON_PORT=1012
+ export CALLMONITOR_PASSWORD=
+ export CALLMONITOR_PHONEBOOKS=callers cache avm
+ export CALLMONITOR_READ_FONBUCH=no
+ export CALLMONITOR_REMOTE_ADDR=169.254.255.255
+ export CALLMONITOR_REVERSE=no
+ export CALLMONITOR_REVERSE_CACHE=transient
+ export CALLMONITOR_REVERSE_PROVIDER=
+ export CALLMONITOR_USERNAME=callmonitor
+ PATH=/sbin:/bin:/usr/sbin:/usr/bin:/mod/sbin:/mod/bin:/mod/usr/sbin:/mod/usr/bin
+ . /mod/pkg/callmonitor/usr/lib/callmonitor/system.sh
+ alias ?=__is_true
+ LC_ALL=C busybox nc -z
+ egrep -q (illegal|invalid) option -- z
+ . /mod/pkg/callmonitor/usr/lib/callmonitor/applets/rc.callmonitor.sh
+ DAEMON=callmonitor
+ require rc
+ local lib=rc
+ shift
+ local file=/mod/pkg/callmonitor/usr/lib/callmonitor/modules/rc.sh
+ __is_true LIB_rc != 1
+ let LIB_rc != 1
+ let LIB_rc = 1
+ . /mod/pkg/callmonitor/usr/lib/callmonitor/modules/rc.sh
+ require modreg
+ local lib=modreg
+ shift
+ local file=/mod/pkg/callmonitor/usr/lib/callmonitor/modules/modreg.sh
+ __is_true LIB_modreg != 1
+ let LIB_modreg != 1
+ let LIB_modreg = 1
+ . /mod/pkg/callmonitor/usr/lib/callmonitor/modules/modreg.sh
+ require file
+ local lib=file
+ shift
+ local file=/mod/pkg/callmonitor/usr/lib/callmonitor/modules/file.sh
+ __is_true LIB_file != 1
+ let LIB_file != 1
+ let LIB_file = 1
+ . /mod/pkg/callmonitor/usr/lib/callmonitor/modules/file.sh
+ FIFO=/var/run/callmonitor/fifo
+ FIFO_DIR=/var/run/callmonitor
+ ensure_dir /var/run/callmonitor
+ local dir
+ [ -e /var/run/callmonitor ]
+ PIDFILE=/var/run/callmonitor/pid/callmonitor
+ [ ! -r /mod/etc/conf/callmonitor.cfg ]
+ have monitor
+ [ -e /mod/pkg/callmonitor/usr/lib/callmonitor/features/monitor ]
+ mod_register
+ local flash=/tmp/flash/callmonitor
+ mkdir -p /tmp/flash/callmonitor
+ have webif
+ [ -e /mod/pkg/callmonitor/usr/lib/callmonitor/features/webif ]
+ modreg cgi callmonitor Callmonitor
+ modreg daemon callmonitor
+ modreg extra callmonitor Wartung 1 maint
+ have monitor
+ [ -e /mod/pkg/callmonitor/usr/lib/callmonitor/features/monitor ]
+ modreg extra callmonitor Testanruf 1 testcall
+ modreg extra callmonitor  2 exec
+ modreg file callmonitor rules Regeln 0 rules
+ have phonebook
+ [ -e /mod/pkg/callmonitor/usr/lib/callmonitor/features/phonebook ]
+ modreg extra callmonitor Rückwärtssuche 1 reverse
+ modreg file callmonitor callers Telefonbuch 1 callers
+ have phonebook
+ [ -e /mod/pkg/callmonitor/usr/lib/callmonitor/features/phonebook ]
+ phonebook init
+ have monitor
+ [ -e /mod/pkg/callmonitor/usr/lib/callmonitor/features/monitor ]
+ try_start
+ echo callmonitor is disabled
callmonitor is disabled
+ exit 1

und hängt sich dabei nicht auf.
Meine relativ volle .config ist beigefügt. Und ja, die restlichen Sachen laufen dann auf der Box stabil und sind schon mit 6.93 über mehrere Monate (allerdings ohne ReplaceKernel) stabil gelaufen.

MfG

 

[hermann72pb]

Ich erlaube mir Doppelposting, um die Ursache für das Problem etwas detaillierter zu erläutern.
Beim genauen Betrachten meines ps-Ausschnittes war mir eine Zeile aufgefallen:

 4854 root      1404 S    {busybox} wget -U callmonitor/98d3ccce65 http://www.billiger-telefonieren.de/vorwahlrechner/?num=000ZENSIERT00000000000 -q -O -

Ich verstehe zwar nicht, warum callmonitor während des Initialisierens beim deaktivierten Dienst dennoch "nach Hause telefonieren" will, um irgendwelche Vorwahlen zu berechnen, aber sei es drum. Wenn die Box zu diesem Zeitpunkt nicht gerade online ist, wird es dann irgendwann mal problematisch... Meine "supertolle" VDSL-Verbindung mit der immer komplizierter werdenden AVM-Technologie schein zwar von Firmware zur Firmware immer mehr zusätzliche kBits zu gewinnen (letzer Sprung war von 57000 auf 60000), dafür braucht aber die Box gefühlt immer länger, um sich überhaupt erstmal zu SYNCen. Derzeit liegt diese Zeit bei mir nicht unter 4-5 Minuten nach dem Starten der Box.
Die Abhilfe schafft z.B. das Deaktivieren der Option "Callmonitor->Rückwärtssuche->Anbieter für Vorwahlen->Notfalls Vorwahl nachschlagen bei", sodass dort "niemandem" steht (s. Bild im Anhang). In dem Falle wird vermutlich kein wget beim bloßen Initialisieren vom callmonitor aufgerufen.

Das Ganze könnte tatsächlich, wie PeterPawn vermutet, mit dem geänderten Startverhalten von AVM zu tun haben. Vermutlich überwachen sie jetzt den Start mit diesem 168 Sekunden-Watchdog anders als zuvor und schlagen früher Alarm, der zum Reboot führt. Ob es eine gute Idee von AVM ist, die Box in die Dauerreboot-Orgie hinzuschicken, lasse ich hier so stehen. Andererseits gefällt mir aber dieses dauerwartende wget von callmonitor irgendwie auch nicht so wirklich... Als ich noch zur Steinzeit der Fritzbox damals für die 7050 den Downloader auf die Beine gestellt hatte, hatte ich die Wartezeit und die Wiederholversuche beim wget startk begrenzt, sodass auch bei einer fehlenden Verbindung die Box trotzdem durchstarten konnte. Meiner Meinung nach sollte man es hier mit dem wget ähnlich machen.

MfG

 

[Coolzero82]

Hallo,
also ich kann das Problem nochmals bestätigen, auf der 6590 führt Callmonitor im Image immer zum dauer reboot.
Ich hab mal die Support Dateien erstellt, während der kurzen Zeit vor dem nächsten reboot, vieleicht hilft das weiter

 

[stoney]

In den Supportdaten stehen auch teils persönliche Dinge.

Ich würde warten bis jmd genauere Parts davon erfragt anstatt diese Datei mit aller Welt zu teilen.

 

[hermann72pb]

Ich hatte doch das Problem und das Workaround oben gepostet. In den zwei Posts oben wurde es doch von mir ausführlich durchgekaut. Darum hatte ich es auch auf "gelöst" gesetzt.
Die https-Fähigkeit trägt dem Reboot-Loop gar nicht bei, wie ich schon ebenfalls im anderen Thread gesagt hatte und wie es im Posting #2 eindeutig zu sehen ist: Der "hängende" wget will gar keine https-Seite aufrufen, sondern eine http-Seite mit irgendwelchen Vorwahlen.
Dumping aus der Support Datei kannst du hier schon posten, wenn du deine persönlichen Daten daraus entfernst, wie ich es oben z.B. bei meinem "ps" gemacht hatte. Aber natürlich nicht die ganze Datei, sondern nur die Anteile mit dem Crash-Log. Wenn jedoch deine CrashLog-Daten meinen bereits geposteten Daten ähnlich sind, macht es wenig Sinn, sie hier zu posten, um nochmal eine alles und nichts aussagende Meldung zu sehen, dass ctlmgr mit dem Watchdog und libc.so.1 an der Adresse XY gecrasht ist.

Hast du die Option im Callmonitor deaktiviert, die ich oben genannt hatte?

MfG

 

[Coolzero82]

Hallo,
nein habe ich nicht, das hatte ich tatsächlich überlesen den Workaround, allerdings sehe ich das Thema auch nicht als gelöst an, denn das grundsatz Problem besteht ja weiterhin, auch wenn dein Workaround erstmal funktioniert, verstehe das doch richtig, mit deinem Workaround müsste ich nach jedem Box neustart (Wieso auch immer ich die neustarten will/muss) immer wieder die rc.callmonitor manuell "killen" um nicht den dauer reboot zu haben?!

 

[hermann72pb]

@Coolzero82 Du hättest es mal einfach ausprobieren sollen. Killen solltest du rc.callmonitor nur einmalig, damit du genug Zeit hast unter FREETZ die besagte Option zu deaktivieren. Evtl. geht es sogar ohne zu killen, wenn du zum bestimmten Zeitpunkt die FREETZ-WebIF gerade erwischst und schnell in die Optionen von callmonitor gehst. Ich hatte es jedoch auf die Art und Weise nicht ausprobiert. Es kann sein, dass rc.callomonitor an der Stelle seine Einstellungen noch nicht geladen hat. Wenn du die markierte Option deaktivierst, wird callmonitor diesen wget-Aufruf beim Starten der Box nicht mehr durchlaufen, die Box starten dann erfolgreich durch und verfällt nicht in Dauerreboot-Schleife.
Und wenn ich es hier auf "gelöst" setze, dann ist es weitgehend gelöst. Denn callmonitor wird von Andreas Bühmann schon seit Jahren nicht mehr weiterentwickelt. Wer soll denn das Problem deiner Meinung nach lösen? Wenn wir Glück haben und trac irgendwann mal funktioniert, kann man zu dem Thema dort einen Ticket eröffnen (was ich viel lieber getan hätte, als diese lange Diskussion hier zu führen) und wenn sich dann jemand finden würde, meinen Vorschlag von oben mit der Begrenzung der wget-Wartezeit zu realisieren und postet dazu am Besten dann gleich einen patch gegen trunk, dann wird es von den Schreibberechtigten irgendwann mal in den trunk übernommen. So ist die typische Vorgehensweise bis jetzt gewesen.
Das hier beschriebene Problem wird aber vermutlich auf "produktiven" Boxen kaum auftreten. Denn in meinem spezifischen Fall benötigt meine DSL-Verbindung (wie bereits oben beschrieben) 4-5 Minuten, bis sie überhaupt steht. Im Normalfall dürfte die DSL-Verbindung vermutlich 1-2 Minuten nach dem Start der Box bereits stehen. In einem solchen Fall wird dieser Watchdog vermutlich nicht zuschlagen. Denn, wenn die Verbindung bereits steht, kann ich callmonitor ohne Probleme laden und entladen (nicht zu verwechseln mit dem start und stop!). @Coolzero82 Wetten, du testest es an der Box, die gar nicht online ist? Es würde evtl. schon mal helfen, wenn du dem callmonitor ermöglichst beim Laden "nach hause zu telefonieren".
Ist es jetzt ausführlich genug durchgekaut? Und poste bitte nicht durch die zwei benachbarten Threads quer durch. Ich hatte dir doch an den entsprechenden Stellen bereits mehrfach erklärt, wo die Ursache für dein Problem liegt.

 

[Coolzero82]

Hi, war keine Kritik nur eine Nachfrage, muss dich allerdings leider enttäuschen, die Box ist die ganze Zeit online, bzw. die Box ist angeschlossen und ohne das ich es jetzt gestoppt hätte, aber normal ist die Internet Verbindung nach dem Boot direkt verfügbar!

 

[hermann72pb]

Aber hast du es jetzt mit dem Deaktivieren dieser Option ausprobiert oder nicht?
Es wäre nicht schlecht zu wissen, was diese Option da physikalisch überhaupt tut, außer beim Laden die eigene Vorwahl draußen zu prüfen (so ist zumindest mein Verständnis für die Option). Wenn ich mit meiner Vermutung oben falsch liege, dass es nur an fehlender Verbindung liegt, könnte ich mir da nur zwei Möglichkeiten vorstellen:
1. Die aufgerufene Seite exisitiert nicht, wget scheitert und wartet ewig
2. Zu dem Zeitpunkt, wo wget von Draußen die Vorwahl abfragen will, steht die Verbindung noch nicht (auch bei dir), wget "hängt sich auf" und kriegt es nicht hin, die Seite abzurufen, wenn die Verbindung später da ist
Beides entspricht eigentlich nicht dem normalen Verhalten von wget, was ich so kenne. Darum ist es hier eine reine Spekulation. Es wäre nicht schlecht, wenn du das ausprobierst, was ich oben als Workaround gepostet habe und über deine Erfolge/Misserfolge berichtest.
Mir ging es in erster Linie darum callmonitor "ruhig zu stellen". Ich habe es zwar im Image drin und will callmonitor auch langfristig wieder nutzen, momentan ist callmonitor bei mir aber nicht gestartet und deaktiviert. Auch die Clients sind weder installiert noch eingerichtet. Ich hatte callmonitor vor 5-7 Jahren intensiv genutzt, spätestens mit dem Umzug der Rechner auf Win10 war es aus und ich hatte die Clients noch nicht "nachgezogen".

 

[hermann72pb]

Seit Changeset 14997 gibt es im trunk auch eine entsprechende Workaround-Lösung für callmonitor-Problem:
https://github.com/Freetz/freetz/commit/14a4c66115d9530c09fce7c66b86a4bdb5cc6e37