[GELÖST] FBF7141: Zuerst Zombies ohne ende, dann Dauerreboot

[xemacs]

hallo, mal an die linuxspezialisten unter euch
ich habe mir n image erstellt für meine fbf 7141 (mit der .37 firmware)
drinnen sind:
dropbear
openntpd
pptpd
dnsmasq
inadyn
virtualip CGI

das ganze wurde mit den entsprechenden kerneloptionen von pptpd gebaut und folglich auch mit replace kernel zusammengestellt

habe vorhin das image geflasht, darauf hin lief die box ohne großes rummucken
später hat sie kurz rebootet lief dann aber eine stunde weiter (war nicht zuhause)

als ich per SSH nachschaute fielen mir ca 40 zombie prozesse auf (alles mehrfach: multid, dnsmasq, sh, ps ,igdd, ctlmgr)

da diese von init einfach nicht weggeräumt werden wollten (was ja eigentlich geschehen sollte) bootete ich die box neu, sie lief dann ca 1 minute, danach verfiel sie quasi in todesstarre (reboot, 1 ping reply, danach tot und wieder automatischer reboot)

schlussendlich hat nur ein recover geholfen


hat einer irgendeine idee an was das liegt?

UPNP habe ich natürlich wie schon hier mehrfach angesprochen abgeschaltet

[EDIT]
Amüsant ander sache ist jedoch, mein Testsystem (alte FritzBox Fon) läuft mit genau diesen paketen seit ca 1 woche ohne crashes o.ä.

 

[kriegaex]

Das könnte daran liegen, daß die 7141 eine Firmware .37 hat, die Fon eine .33. Die .37 hat ja bekanntermaßen von AVM bestätigte Probleme mit UPnP. A propos: Du hast UPnP abgeschaltet, aber trotzdem igdd-Prozesse? Das paßt irgendwie nicht zusammen. Am besten entfernst Du die UPnP-Sachen per Menuconfig mal ganz aus dem Image, um zu testen, ob das irgendwie weiter hilft.

 

[xemacs]

danke für die schnelle antwort!

kann das problem mit dem igdd die probleme mit den anderen zombies verursachen?

ich persönlich glaube eher, das dass problem beim ersetzten kernel liegt!

 

[kriegaex]

Wenn Du das glaubst, wieso hast Du den Kernel dann nicht einfach mal weggelassen, um das zu verifizieren? Jedenfalls gibt es diverse Benutzer mit eigenem Kernel, die keine Probleme haben, aber ich weiß von Zombie-igdd-Prozessen, die es sogar schaffen, einen 60-MB-Swap zuzumüllen. Hast Du beides mal versucht?

 

[xemacs]

guten morgen!
also ich habe gestern nacht noch einen versuch gestartet mit einem image ohne igdd , es entstanden trotzdem zombies

das kernel replacen ist notwendig, sonst fehlen einige crypto funktionen

wenn man replace kernel weglässt geht die box sofort in einen deadlock

mein momentanes setup ist nun wie beschrieben nur ohne pptpd , diesen habe ich auf die alte fritzbox ausgelagert, diese lösung läuft /zumindest bisher) stabil

 

[kriegaex]

Zombies wovon? Nicht jeder Dienst, der mehrfach läuft, ist ein Zombie (z.B. die üblichen vier websrv-Prozesse). Aber ich glaube Dir schon, daß es Zombies gibt. Welche sind es genau? Daraus kann man evtl. Rückschlüsse darauf ziehen, wo sie gestartet werden und was an dem Skript evtl. nicht stimmt. Zur Not kannst Du mal Log-Ausgaben in die "verdächtigen" Skripten einbauen, um zu sehen, was da passiert. Evtl. schlägt eine Prüfung fehl, ob ein Prozeß schon läuft. Bei einem grep auf die Ausgabe von ps kann ich mir das z.B. gut vorstellen, evtl. auch bei der Prüfung auf ein PID-File, das nicht (mehr) existiert. Alles reine Spekulation.

Es könnte auch speziell an pptpd liegen, wenn es ohne stabil läuft. Heißt "stabil" dann in dem Zusammenhang auch, daß es damit keine Zombies mehr gibt?

 

[xemacs]

also es sind definitiv zombies (ps zeigt mir status Z)

diese entstehen von websrv, multid, dsld, ctlmrg, sh, ps, praktisch jeder prozess der mal gelaufen ist und nicht sauber beendet wurde

ich denke das ist ein problem des zombiecollector des kernels, der wird wohl durch irgendwas gestört

 

[RalfFriedl]

Eine Ursache für Zombies ist, wenn das Skript /etc/init.d/rc.S, das auch die debug.cfg aufruft, nicht beendet wird.
Erst wenn dieses Skript beendet ist, kümmert sich init um die anderen Prozesse.

 

[kriegaex]

Dann müßte es im Code nach Deaktivierung des Watchdogs sein, sonst würde ja die Box rebooten. Also schauen wir uns mal das Ende von rc.S an:

echo init-done >/dev/watchdog
if [ -x /usr/bin/dtrace ] ; then
 DTRACE_PARAMS="-D -d2 -d3 -c2 -c3 -nt3 -m -f /var/dtrace.txt"
 /usr/bin/dtrace $DTRACE_PARAMS
fi
mknod /var/flash/debug.cfg c $tffs_major $((0x62))
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then
 . /var/flash/debug.cfg
fi
echo "4" > /proc/sysrq-trigger
#file "stdin", 67
. /etc/init.d/rc.mod 2>&1 | tee /var/log/mod.log

Da kommt also außer debug.cfg noch rc.mod und somit alle DS-Mod-Dienste in Frage, außerdem noch die rc.custom. Genau deshalb ist es ja gut, möglichst viele wegzulassen, um das einzuschränken. Evtl. mal nach Beenden des Watchdogs sowas wie

exec 1> /var/my.log 2>&1

(alle Ausgaben in Logfile umleiten) und, falls das nicht genug ist, auch noch

set -x

(jede Skriptzeile protokollieren) einfügen. Am Ende der rc.custom und evtl. zwischendurch noch ein paar Echos, damit man sieht, wie weit er kommt (falls kein set -x), da müßte dann was zu sehen sein.

 

[xemacs]

ok dann kann ich ohne zu testen mit sehr hoher warscheinlichkeit sagen dass es an pptpd liegt, ohne diesen läuft die box nämlich im moment einwandfrei

 

[kriegaex]

Es wäre trotzdem sinnvoll, uns zu helfen, indem Du den Fehler nachvollziehst und nach Möglichkeit protokollierst, denn sonst wird er nie verschwinden und Du wirst auf dieser Box niemals die Software einsetzen können. Du willst Hilfe von uns, trag also bitte auch zum Lösung von Problemen bei. "Tit for tat", wie man im angloamerikanischen Sprachraum sagt.

 

[xemacs]

ich werde mich nächste woche darum kümmern, da die box momentan als "produktivsystem" läuft
ich werde dann meine testergebnisse hier nochmal posten

vielen dank schonmal für die hilfe bisher!

gruß
marcel

 

[kriegaex]

Vielleicht liegt es an der Hitze und ich habe heute meinen empfindlichen Tag, also nimm es bitte nicht persönlich, aber ich habe solche Aussagen schon so oft gelesen. Alle haben immer genug Zeit, so lange an ihren Boxen herumzuspielen, bis es irgendwie geht, egal ob der Fehler gefunden wurde oder nur das Symptom vermieden wurde, wie in diesem Fall. Dann ist plötzlich alles andere wichtig und die Box produktiv. Das ist meine übrigens auch, wenn ich hier im Forum supporte und deswegen experimentiere, kann ich oft auch nicht telephonieren oder surfen bzw. muß das nachts machen. Geholfen werden soll immer ganz schnell, aber wehe, die Helfer wollen mal eine Information, die etwas zeitaufwendiger zu ermitteln ist.

Du kannst persönlich nicht mehr dafür als alle anderen, wie gesagt. Aber machmal frage ich mich in letzter Zeit wirklich, ob ich mir das noch weiter antun soll hier. Es ist bestimmt die Hitze...

 

[xemacs]

das problem ist dass ich nicht zuhause bin und somit nicht an meine box rankomme, bin erst nächste woche wieder zuhause und kann dann weitertesten.

 

[xemacs]

hallo
ich habe heute mal ein neues image gebaut mit 15.2

die box startete korrekt, habe mich also per ssh eingeloggt
die kiste lief also ein bisschen , nach einem "ps" sah ich da wieder ein haufen zombies
darauf hin habe ich die pptpd binary beendet und siehe da: alle zombies verschwunden!

der fehler ist nun also eindeutig auf pptpd zurückzuführen
evtl sollte ich mal schauen wie ich die neu compiled bekomme!

gruß marcel

 

[kriegaex]

Hast Du zufällig noch gleichzeitig VirtualIP-CGI laufen?

 

[RalfFriedl]

Was passiert, wenn der pptpd von Hand aufgerufen wird? Geht er dann von solbst in den Hintergrund und kommt ein Shell-Prompt, oder passiert dies nicht?

 

[xemacs]

@RalfFriedl: er geht direkt in den background, ohne murren

@kriegaex: ja habe ich, sollte das irgendwie von belangen sein?

 

[RalfFriedl]

Vielleicht ist zu dem Zeitpunkt, wo er automatisch gestartet wird, etwas noch nicht fertig.
Du kannst versuchen, pptpd sicherheitshalber mit & in den Hintergrund zu schicken, um zu sehen, ob damit das Zombie-Problem verschwindet.
Wenn das hilft, kannst versuchen, Meldungen vom pptpd in eine Datei zu schreiben oder den pptpd mit "strace -f" aufrufen, um zu sehen ob/wo er hängt.
Für "strace -f" ist "Replace Kernel" notwendig.

 

[kriegaex]

Ich weiß nicht, ob es von Belang ist, aber man hört immer wieder von Problemen im Zusammenhang mit VirtualIP und OpenVPN. Es ist evtl. besser, Deine Portfreigaben manuell in die ar7.cfg einzutragen. Das ist einfach, wird nur einmal gemacht, geht auch ohne Zusatzpaket und ohne virtuelles LAN-Interface.