SAMBA produziert callmonitor-zombies

[hermann72pb]

Ich hatte an einigen Boxen mit 49, 50 - Firmware (7170, 7141) und einem der letzten Trunks seit 1654 ein seltsames Verhalten beobachtet.
Nach einiger Zeit zeigt ps eine Reihe von Zombies (s. ps-XXX.txt).
Da einige der Zombies callmonitors sind, vermute ich stark, dass diese "Zombierung" was mit callmonitor zu tun hat.

Fall 1 7170:
Ich hatte mal eine "verzombte" 7170 neu gestartet. Die Zombies waren nach dem reboot wieder da. Als ich bei der Box callmonitor deaktiviert hatte und die Box neu gestartet hatte, waren die Zombies weg. Auch nach einem nachträglichen Start von callmonitor (/etc/init.d/rc.callmonitor start) hatte ich zunächst keine Zombies beobachtet.

Fall 2 7141:
Wurde mit aktiviertem callmonitor gestern eingeschaltet. Zunächst keine Zombies in ps. Heute zeigt ps viele Zombies (s. ps-7141-Fall2.txt). Im SYSLOG habe ich was Interessantes entdeckt:

....
Feb 11 13:46:41 fritz user.err telefon[552]: '/var/calllog' script not found!
Feb 11 13:46:41 fritz user.err telefon[552]: '/var/flash/calllog' script not found!
Feb 11 13:46:42 fritz daemon.info callmonitor: [1] EVENT=in:request SOURCE='0XXXXXXXX' DEST='0XXXXXXXXX' SOURCE_NAME='XXXXXXXXXX
.....

Also während des Anrufs (wo callmonitor seine Dienste leistet) kam es zu Problemen mit "calllog"-s.

Fall 3 7170 trunk 1654:
Diese Box hatte ich schon lange nicht mehr beobachtet (uptime 9 days). Wenn man in das Log dieser Box schaut (ps-7170-Fall3.txt), wird man richtig staunen, wie die Box noch lebt...

Hat sonst jemand Probleme mit Zombies?

MfG

 

[olistudent]

Ich hatte mal Zombies mit Ursache Samba untersucht. Leider bin ich da aber nicht weiter gekommen. Aber wenn die Zombies nur mit aktiviertem Callmonitor auftreten, dann hängt es wohl auch daran. Ich würde darauf tippen, dass es sich um ein Problem mit der busybox handelt. Da am Callmonitor schon etwas länger nichts mehr geändert wurde!?

MfG Oliver

 

[hermann72pb]

Ich kann es nicht 100% sagen ob es nur mit aktiviertem callmonitor auftritt, oder ob eine Mischung der Pakete da die Rolle spielt. Aber wie man aus dem Log zum Fall3 sehen kann, scheint es doch mit callmonitor zusammen zu hängen.

MfG

 

[Silent-Tears]

Also ich kann der Sache mit dem Callmonitor eigentlich nciht ganz folgen. Denn ich fahre aktuell auf meiner "Hauptbox" den 1685 (ich weiss, auch nicht wirklich neu), und dort zumindest gibt es keine Probleme.
Was mir im Fall 3 noch auffällt, ist der mehrfache Zombie "[modflash-now]" im Unterschied zum Fall2 und meiner Box.

edit: zusätzlich noch diverse "rm"-Prozesse. Weisst du zufällig noch, warum die alle laufen? Oder liefen?

 

[hermann72pb]

Das war die einzige Box, wo ich (warum auch immer) die Suchergebnisse im Callmonitor als dauerhaft speichere. Mittlerweile hab ich es wieder auf "flüchtig" umgestellt. Es beweist für mich noch mehr, dass es was mit callmonitor zu tun hat, denn:
1. modflash_now nutzt callmonitor wahrscheinlich um seine Suchergebnisse zu speichern
2. rm wird wahrscheinlich danach benutzt um irgendeine temporäre datei zu löschen.
3. Die PIDs werden normalerweise aufsteigend vergeben. Verfolgt man die Reihenfolge und betrachtet man, dass die Zombies immer nach einem gleichen Muster entstehen und rumherum vom callmonitor-Zombie umkreist sind, so verdichten sich die Wolken um callmonitor herum.

Ich will damit nicht sagen, dass callmonitor das Problem ist. Wahrscheinlich steckt das Problem irgendwo anders. Nur die Aufrufe von Callmonitor bringen das Problem ans Licht.

Und zu deiner Frage wegen Reproduzierbarkeit. Ich habe noch eine Reihe von Boxen, wo das Problem (weiß der Geier warum) nicht auftritt. Ich habe zwei 7170 mit einer exakt gleicher Firmware (etwa wie Fall 3). Bei einer der beiden entstehen aber keine Zombies. Und dieser einer Fall ist die mit 49-Firm werkresettete 7170 mit handisch neu angetippten Einstellungen.

MfG

Edit: Ich glaube, dem Problem etwas näher auf die Spuren gekommen zu sein. Alle "zombierten" Boxen hatten SAMBA gehabt. Alleine deaktivieren von Samba (Umstellen von "automatisch" auf "manuell") bringt alle Zombis zum entgültigen Sterben. Während dessen wird Samba logischerweise erstmal gestoppt (und damit wird wahrscheinlich Elternprozess aller Zombies beendet: rc.S oder so) und dann gestartet. Ich muss dazu sagen, dass ich samba einfach "vollständigkeitshalber" reinkomilliert habe. Es wurde bis jetzt noch nicht benutzt. Ich deaktiviere erstmal SAMBA bei allen Boxen und beobachte weiter.

 

[RalfFriedl]

Das ist das Problem, das wir mit Spindown schon mal hatten. In der Prozeß-Liste sieht man, daß das Programm "tee" noch läuft. Das bedeutet, daß von einem der gestarteten Pakete, möglicherweise in diesem Fall vom Callmonitor, die Ausgabedateien nicht geschlossen werden.

 

[australien2006]

Könnte das Problem auch mit diesem Thread zur FB 7050 und Callmonitor Problemen zusammenhängen?

Ich habe den CM gestern deaktiviert und bis jetzt läuft alles ohne Probleme.

 

[hermann72pb]

Kannst du denn bestätigen, dass du Zombies siehst/gesehen hast? Wie gesagt, ich tendiere hier langsam dazu, dass Verursacher in meinem Fall SAMBA ist. Callmonitor-Zombies sind einfach Folgen vom nicht beendeten SAMBA, bzw. rc.S.

MfG

 

[wonderdoc]

Hi,

Ich hatte zuerst auch den Freetz-Samba mit eingebaut gehabt.
Da hatte ich auch Zombis.
Da das Package aber mit den AVM-Samba Probleme hat, habe ich es wieder entfernt.
Nun habe ich eine 29.04.49 mit Trunk 1729(ohne Freetz-Samba) auf meier 7170.
Dort konnte ich noch keine Zombis beobachten.
ps stellt vom Callmonitor 4 Prozesse mit Eintrag "/bin/ash /usr/sbin/callmonitor" und
einem mit "logger -t callmonitor -p daemon.info" da.
Der Callmonitor läuft problemlos.

mfg
Wonderdoc

 

[hermann72pb]

es reicht auch Freetz-SAMBA einfach zu deaktivieren (also nicht automatisch starten) ....
Aber generell hast du recht, ich denke auch, dass es damit zusammen hängt, dass AVM und Freetz Sambas in Querre kommen.

MfG

 

[Silent-Tears]

Dann sollte das ja mit einer aktuellen Revision behoben sein, denn da wird der Samba ersetzt, sollte man ihn auswählen.

Kann das mal jemand testen? Vor heute Abend komme ich da nämlich nicht zu.

 

[RalfFriedl]

Nach der Beschreibung bin ich mir sicher, daß es damit zusammenhängt, daß ein Dienst die Ausgabe zu "tee" nicht schließt. Kannst Du versuchen, herauszufinden, welcher Dienst das ist?

 

[hermann72pb]

wie kann ich es tun?

MfG

 

[RalfFriedl]

Du kannst einzelne Dienste deaktivieren und aktivieren, bis Du einen oder mehrere herausfindest, die einen Einfluß darauf haben, ob Zombies bleiben oder nicht.

Du kannst auch ohne Neustart folgendes versuchen, für alle Dienste:

# Sicherstellen, daß der Dienst gestoppt ist
/etc/init.d/rc.xxx stop
# Dienst starten
/etc/init.d/rc.xxx start | tee /dev/null

Es ist aber nicht sicher, ob bei diesem Weg das Ergebnis genau das gleiche ist, wie wenn die Dienste automatisch gestartet werden.
Für xxx muß der Name des Dienstes eingesetzt werden.
Wenn bei einem dieser Aufrufe nach der Zeile mit "start" nicht der Kommando-Prompt kommt, stimmt etwas nicht mit dem Dienst, bzw. der Art, wie er gestartet wird.

 

[wonderdoc]

Dann sollte das ja mit einer aktuellen Revision behoben sein, denn da wird der Samba ersetzt, sollte man ihn auswählen.

Ich habe nun mal eine Image mit Trunk1826 mit 29.04.49 gebaut.
Ich habe den Freetz-Sambe 3.0.24 aktiviert.
Ich kann keine Zombies ausmachen.
Mir ist aber aufgefallen, daß nur der smbd ersetzt wird.
Es ist nicht das gewohnte Samba-Package.

mfg
Wonderdoc

 

[matze1985]

gibt es eigentlich was neues zu den Zombies?
Hab mal bei mir nachgeschaut und ich bekomme ne menge nach ein paar stunden:

uptime ; echo "" ; ps | grep Z
 21:41:06 up  9:21, load average: 0.16, 0.15, 0.08

  PID  Uid        VSZ Stat Command
  489 root            Z N [ctlmgr]
  519 root            Z N [hub]
  610 root            Z N [hub]
  611 root            Z N [storage]
  619 root            Z N [storage]
  644 root            Z   [igdd]
  688 root            Z   [dnsmasq]
  691 root            Z   [multid]
  692 root            Z   [multid]
  699 root            Z   [multid]
  700 root            Z   [multid]
  705 root            Z   [dsld]
  717 root            Z   [voipd]
  819 root            Z   [sh]
 1029 root            Z   [callmonitor]
 1030 root            Z   [logger]
 1124 root            Z N [usb-stor-scan]
 1125 root            Z N [scsi_eh_1]
 1132 root            Z N [usb-storage]
 1134 root            Z N [usb-stor-scan]
 1167 root            Z   [dropbear]
 1290 root            Z N [run_mount]
 1289 root            Z N [run_mount]
 1352 root            Z   [openvpn]
 1403 root            Z   [stunnel]
 1431 root            Z   [sh]
 1444 root            Z   [multid]
 1450 root            Z   [sh]
 1503 root            Z N [tr069starter]
 1504 root            Z N [tr069starter]
 1508 root            Z N [tr069starter]
 1511 root            Z N [tr069starter]
 1756 root            Z N [smbd]
 1762 root            Z N [smbd]
 1787 root            Z N [smbd]
 1975 root            Z   [sh]
 2204 root            Z   [sh]
 2370 root            Z   [sh]
 2946 root            Z N [printer]
 2991 root            Z N [printserv]
 3017 root            Z N [make_devices]
 3019 root            Z N [make_devices]
 3041 root            Z N [printer]
 3064 root            Z   [scsi_eh_2]
 3065 root            Z   [usb-storage]
 3069 root            Z   [usb-stor-scan]
 3071 root            Z N [make_devices]
 3079 root            Z N [make_devices]
 3091 root            Z N [storage]
 3122 root            Z N [storage]
 3176 root            Z N [printer]
 3200 root            Z N [make_devices]
 3243 root            Z N [printserv]
 3283 root            Z N [run_mount]
 3338 root            Z N [tr069starter]
 3339 root            Z N [tr069starter]
  615 root            Z N [make_devices]
  621 root            Z N [make_devices]
  640 root            Z N [printer]
  748 root            Z   [callmonitor]
  793 root            Z   [callmonitor]
  813 root            Z   [callmonitor]
  986 root            Z   [callmonitor]
 1026 root            Z   [callmonitor]
 1082 root            Z   [callmonitor]
 1110 root            Z   [usb-stor-scan]
 1111 root            Z N [make_devices]
 1146 root            Z N [storage]
 1164 root            Z N [storage]
 1212 root            Z N [printer]
 1261 root            Z N [run_mount]
 1339 root            Z N [printserv]
 1366 root            Z N [tr069starter]
 1367 root            Z N [tr069starter]
 1557 root            Z   [callmonitor]
 1590 root            Z   [callmonitor]
 1626 root            Z   [callmonitor]
 1629 root            Z   [callmonitor]
 1685 root            Z   [callmonitor]
 1751 root            Z N [make_devices]
 1752 root            Z N [make_devices]
 1777 root            Z N [printer]
 2082 root            Z   [callmonitor]
 2123 root            Z   [callmonitor]
 3448 root            Z   [callmonitor]
 3481 root            Z   [callmonitor]
 3518 root            Z   [callmonitor]
 3521 root            Z   [callmonitor]
 3584 root            Z   [callmonitor]
 3599 root            Z   [callmonitor]
 3632 root            Z   [callmonitor]
 3669 root            Z   [callmonitor]
 3707 root            Z   [callmonitor]
 3721 root            Z   [callmonitor]
 3903 root            Z   [callmonitor]
 3928 root            Z   [callmonitor]
 3972 root            Z   [callmonitor]
  360 root            Z   [callmonitor]
  413 root            Z   [callmonitor]
  526 root            Z   [callmonitor]
  564 root            Z   [callmonitor]
  810 root            Z   [callmonitor]
 1929 root            Z   [callmonitor]
 1976 root            Z   [callmonitor]
 1986 root            Z   [callmonitor]
 2699 root            Z   [sh]
 2756 root            Z   [index.cgi]
 2967 root            Z   [daemons.cgi]
 3309 root            Z   [sh]
 3514 root            Z   [sh]
 3572 root            Z   [index.cgi]
 3833 root            Z N [printer]
 3880 root            Z N [printserv]
 3989 root            Z N [make_devices]
 3994 root            Z N [make_devices]
 4012 root            Z N [printer]
  380 root            Z   [callmonitor]
  423 root            Z   [callmonitor]
  510 root       1408 S   grep Z

Meine Config habe ich mal angehängt.
Habe es mit Samba von AVM und dem Replace(Samba-Paket) aus dem aktuellen Trunk ausprobiert und es trat bei beidem auf.

edit:
Hab jetzt nachmal etwas nachgeschaut und folgendes gesehn:

ps | grep tee
  742 root       1412 S   tee /var/log/mod.log
 2362 root       1408 S   grep tee

und nach

/var/mod/root # kill 742
/var/mod/root # ps | grep tee
 2365 root       1408 S   grep tee

sind alle weg:

/var/mod/root # ps | grep Z
  PID  Uid        VSZ Stat Command
 2367 root       1408 S   grep Z

und ich habe jetzt wieder massig speicher

Naja es sieht also so aus, wie schon mal gesagt wurde, das beim start ein Programm seinen ausgabe nich schließt und deswegen der tee nach /var/log/mod.log offen bleibt.

Leider fliege ich morgen recht früh nach Amerika und schaffe es heute nciht noch etwas rum zu spielen.
Aber ich werde bei gelegenheit mal versuchen den Start der Pakete mit

# Sicherstellen, daß der Dienst gestoppt ist
/etc/init.d/rc.xxx stop
# Dienst starten
/etc/init.d/rc.xxx start | tee /dev/null

nachzuvollziehen.
Gibt es sonst vielelicht ne vermutung woran es liegen könnte?

 

[olistudent]

Der Samba ist Schuld. Aber das steht schonmal hier im Thread...

MfG Oliver

 

[RalfFriedl]

Kann mal jemand, bei dem die Zombies vorhanden sind, mit lsof die offenen Dateien von samba kontrollieren?

lsof -nP -c smbd -c nmbd

 

[kriegaex]

Grundsätzlich habe ich bei allen Zombie-Problemen in der Vergangenheit immer gesehen, daß der Boot-Prozeß nicht bis zum Ende durchlief, unabhängig davon, welcher Dienst am Ende schuld war. D.h., fürs Debugging sollte es immer etwas bringen, nach und nach einzelne Dienste zu deaktivieren, bis der Schuldige gefunden ist. Hier ist er ja schon bekannt, aber allgemein gilt dieser Hinweis.