Callmonitor produziert wieder zombies

[hermann72pb]

Habe mächtige Probleme mit einer 7270 (freetz-devel-3256) und Callmonitor 12.5. Zunächst hatte Callmonitor syslog damit zugemüllt, dass die Schnittstelle nicht aktiviert sei. Nachdem ich die Schnittstelle vor Ort aktiviert hatte, ging es wenigstens damit weiter. Nun scheint eine analoge Schnittstelle (Telefon) tot zu sein. Ich vermute, dass es etwas mit dem Callmonitor zu tun hat.

PS liefert nämlich ein Paar zombierte callmonitors und merkwürdige wget / sed Aktionen, die zum Zeitpunkt definitiv da nicht ausgeführt werden sollten, sondern anscheinend schon seit Tagen dort hängen.

/var/mod/root # ps
  PID USER       VSZ STAT COMMAND
    1 root      1188 S    init
    2 root         0 SWN  [ksoftirqd/0]
    3 root         0 SW   [watchdog/0]
    4 root         0 SW<  [events/0]
    5 root         0 SW<  [khelper]
    6 root         0 SW<  [kthread]
   18 root         0 SW<  [kblockd/0]
   32 root         0 SW   [pdflush]
   33 root         0 SW   [pdflush]
   34 root         0 SW<  [kswapd0]
   35 root         0 SW<  [aio/0]
   72 root         0 SW   [pm_info]
   76 root         0 SW<  [CPMAC]
   80 root         0 SW   [mtdblockd]
  102 root         0 SW   [tffsd_mtd_0]
  183 root         0 SW   [cleanup_timer_f]
  350 root         0 SW   [dectuart_route]
  358 root         0 SWN  [jffs2_gcd_mtd5]
  366 root      1340 S    /bin/sh /etc/init.d/rc.S
  405 root         0 SW<  [capi_oslib]
  406 root         0 SW<  [capi_oslib]
  407 root         0 SW   [capitransp]
  413 root         0 SW   [glob_codecs]
  417 root         0 SW   [avm_dect_thread]
  434 root         0 SW<  [khubd]
  558 root         0 SW<  [scsi_eh_0]
  594 root      8728 S N  ctlmgr
  874 root      2848 S    hostapd -B /var/tmp/hostapd_topology-ath0
  877 root      8728 S N  ctlmgr
  880 root      8728 S N  ctlmgr
  882 root      7556 S    igdd
  883 root      8728 S N  ctlmgr
 1070 root      3080 S    dsld -i -n
 1125 root      5764 S    telefon a127.0.0.1
 1130 root      4896 S <  voipd
 1133 root      2356 S    pbd
 1134 root      2356 S    pbd
 1140 root      1364 S    /usr/sbin/inetd
 1143 root      2356 S    pbd
 1144 root      2356 S    pbd
 1145 root       844 S    /bin/run_clock -c /dev/tffs -d
 1186 root      5764 S    telefon a127.0.0.1
 1187 root      5764 S    telefon a127.0.0.1
 1188 root      5764 S    telefon a127.0.0.1
 1191 root         0 SWN  [kdsld_token]
 1212 root      3068 S    dect_manager
 1221 root      1368 S    httpd -P /var/run/webcfg.pid -p 81 -c /mod/etc/httpd.conf -h /usr/mww/ -r Freetz
 1246 root      1368 S    syslogd -L -O /var/log/loglog -b 5 -s 10
 1367 root      1156 S    /sbin/chronyd -f /var/tmp/chrony.conf
 1377 root      7556 S    igdd
 1378 root      7556 S    igdd
 1379 root      7556 S    igdd
 1405 root      5764 S    telefon a127.0.0.1
 1406 root      5764 S    telefon a127.0.0.1
 1407 root      5764 S    telefon a127.0.0.1
 1467 root      1508 S    /bin/ash /usr/sbin/callmonitor
 1472 root      1368 S    logger -t callmonitor -p daemon.info
 1488 root      1508 S    /bin/ash /usr/sbin/callmonitor
 1491 root      1508 S    /bin/ash /usr/sbin/callmonitor
 1492 root      1508 S    /bin/ash /usr/sbin/callmonitor
 1493 root      1368 S    busybox nc 127.0.0.1 1012
 1494 root      1508 S    /bin/ash /usr/sbin/callmonitor
 1593 root      1228 S    dropbear -p 22 -R
 1606 root      1368 S    httpd -P /var/run/webcfg-wol.pid -p 82 -c /mod/etc/httpd-wol.conf -h /mod/pkg/wol/usr/mww-wol/ -r Wake-on-LAN
 1652 root      2248 S    nmbd -D -s /mod/etc/smb.conf
 1663 root      1188 S    init
 2960 root         0 SW<  [scsi_eh_2]
 2961 root         0 SW<  [usb-storage]
 3343 root      3020 S N  smbd -D -s /mod/etc/smb.conf
 9430 root      1508 S    /bin/ash /usr/sbin/callmonitor
 9433 root      1512 S    /bin/ash /usr/sbin/callmonitor
 9498 root      1512 S    /bin/ash /usr/sbin/callmonitor
 9500 root         0 Z    [callmonitor]
 9504 root         0 Z    [callmonitor]
 9505 root      1512 S    /bin/ash /usr/sbin/callmonitor
 9506 root      1512 S    /bin/ash /usr/sbin/callmonitor
 9510 root      1512 S    /bin/ash /usr/sbin/callmonitor
 9511 root      1512 S    /bin/ash /usr/sbin/callmonitor
 9513 root      1376 S    wget -U callmonitor/1.12.5 -q -O - http://www.dastelefonbuch.de/?la=de&kw=00495XX49XX4X2&cmd=search
 9514 root      1512 S    /bin/ash /usr/sbin/callmonitor
 9515 root      1380 S    sed -n -e  /kein Teilnehmer gefunden/ { s/.*/NA:/; p; q } /<table[^>]*class="[^"]*\(bg-0[12]\|entry\)/,\#<td class="col4"# { \#<di
11064 root      1456 S    dropbear -p 22 -R
11065 root      1200 S    -sh
11408 nobody     956 S    dnsmasq --pid-file=/var/run/dnsmasq/dnsmasq.pid -p 53
11416 root      2524 S    multid
11530 root      1180 R    ps

Die Telefonnummer hatte ich verständlicherweise etwas ge-Xt.

MfG

 

[olistudent]

Welche Firmware nutzt du? Mit der neuesten AVM Labor scheint es Probleme zu geben, weil AVM ein neues Anmelde-Verfahren für das Webinterface eingeführt hat.

MfG Oliver

 

[hermann72pb]

Nein, nein. Das ist die klassische 70-ger Firmware, keine Labor. Übrigens, diese Box ist irgendwie irreparabel auf dem Analogport gestorben. Diese wget und sed - Sachen samt callmonitor-Zombie könnten zu dem Moment des Sterbens des Analogports aufgetreten haben. Die Box werde ich höchstwahrscheinlich bei AVM austauschen. Dem Betroffenen hatte ich heute eine Ersatzbox hingeschickt (glücklicherweise hatte ich eine in der Schublade). Auf diese Austauschbox hatte ich den aktuellen Trunk samt Callmonitor 1.13 geflasht. Mal sehen ob 1.13 stabiler ist als 1.12. Diese wget/sed-Sachen hängen sehr stark mit der Veränderung der Webseite des Suchanbieters. Und buehmann verändert da mit Sicherheit von Version zu Version die Suchalgorithmen.
Der eigentliche Sinn von meinem Posting ist, dass man bei Callmonitor-Sourcen um wget/sed herum schaut, ob sie sich nicht in einem ewigen Download/Suche verhacken. sed zum hängen zu bringen ist sehr leicht. Das hatte ich schon oft geschafft. Aber meistens (wenn schon, dann schon) hängt sed dann immer und nicht Ereignisabhängig.

Edit: Übrigens, so als Tipp an Andreas, wenn ich überhaupt hier die Tipps geben darf. Schließlich machst du es mit callmonitor schon seit Jahren. Ich hatte hier mal zwei Skripte gepostet gehabt zur Bearbeitung von betamax-Accounts: betamax.sh und sendsms.sh. Dort hat man eine ähnliche Problematik, dass man sich durch die Webseite durchkämpfen muss, um an die benötigten Infos zu gelangen. Im Unterschied zu meinem Vorgänger, von dem ich die Skripte übernommen hatte, hatte ich aber die Suchstrategie etwas geändert. Ich schmeiße nämlich im ersten Schritt alle html-Tags und java-code raus. Und im zweiten Schritt suche ich nach den bestimmten Textmustern. So wie du es machst, ist der klassische Weg, aber du "hängst dich" mit den sed-Suchmustern an die html-Tags, die sich leider vom Seitenanbieter aus relativ oft ändern.

MfG

 

[buehmann]

Hallo Oliver,

bin gerade zufällig über diesen Thread gestolpert.

Mit der neuesten AVM Labor scheint es Probleme zu geben, weil AVM ein neues Anmelde-Verfahren für das Webinterface eingeführt hat.

Oh, wie schön. Gibt es irgendwo schon genauere Infos, wie das neue Verfahren funktioniert?

@hermann: Danke für den Hinweis. Allerdings sind auf den meisten Telefonbuch-Seiten halt die Tags und nicht die Textinhalte die besten Anhaltspunkte, um die gewünschten Informationen zu finden. Aber die Anzahl der Änderungen hält sich in Grenzen.

Zu wget/sed: sed hängt in einer Pipe hinter wget, wartet also auf dessen Ende. Auf das ganze wartet der entsprechende Callmonitor-Prozess, der für den konkreten Anruf erzeugt wurde. Die Frage ist also, warum wget ewig blockiert ...

Andreas

 

[olistudent]

Ich nehme an, dass das Problem gelöst ist?

MfG Oliver

 

[hermann72pb]

Naja, sagen wir mal so: Es ist nicht mehr aufgetreten. Und abgesehen von den mysteriösen Umständen, die das ausgelöst hatten, habe ich auch kein Schema, ob solches Verhalten überhaupt reproduzierbar ist. Lass uns mal dieses Thread hier einfach so offen stehen. Vielleicht meldet sich noch jemand. Aber aktiv und intensiv nach dem Fehler suchen würde ich nicht unbedingt.

MfG

 

[olistudent]

Ich hatte das bei meiner 7170 heute auch. Aber nicht näher untersucht. Nach einem Callmonitor-Neustart waren die Prozesse weg.

MfG Oliver

 

[hermann72pb]

Waren das nur callmonitor-Zombies oder diese wget/sed-Prozesse? Denn irgendwie kann ich es auch nicht nachvollziehen, dass wget "stecken bleibt". Denn normalerweise sollte wget schon irgendwie terminieren, selbst wenn die Gegenstelle irgendwelche Probleme macht.

MfG

 

[olistudent]

Ich weiß nur noch, dass es ein sed war. Keine Ahnung, ob auch ein wget dabei war. Das nächste mal werde ich genauer hinschauen.

MfG Oliver