Prozesse nicht tötbar mit Kill und Co.

[niels]

Hallo Listenleutz,

habe hier ein 5.5 PRERELEASE - aber auch schon auf 5.4 den Effekt...

Zuweilen bleiben Prozesse "stehen" - scheinen nicht mehr aktiv zu arbeiten / zu laufen (zombies?!?). Ich kann diese mit den mir bisher bekannten Methoden nicht wegräumen und auch sonst nicht beeinflussen:

kill
kill -9
kill -HUP

auch mit dem rkill Tool oder aus top heraus (ist das nicht eh das selbe kill?) passiert nix (könnte ja am "kill" Kommando liegen). Diese Prozesse bleiben mir dann bis zu einem Reset / OS Neustart erhalten - einige belegen ja auch ärgerlicherweise feste Ports, sodas ich dort nicht einfach andere Instanzen anbinden könnte vorübergehend...

Auch habe ich noch keinen Weg gefunden, die Prozesse zu überwachen und bei Bedarf etwas unternehmen zu können.

Die Prozesse sind entweder meist (python2.4/2.3) Zope Server Instanzen oder Amavisd-NG Eltern wie Kinder (perl5.8.8). Habe nun mehrfach Updates (kern, world ports usw.) über Monate gemacht - der Effekt ist geblieben...

Wer weiss da weiter, hat da Rat oder weiss gar, was da schief geht?


vielen Dank und beste Grüße,

Niels.

 

[Kamikaze]

Das klingt äußerst seltsam. Kannst du Hardwareprobleme mit CPU odr Speicher ausschließen?

 

[niels]

...hmmm, kann ich sicher nicht zu 100%. Es ist ein Dual XEON mit 2GB RAM. Hatte zu Beginn vor einem Jahr Probleme mit ACPI und dem damals nagelneuen BIOS, was wohl auch net ganz sauber war.

Bin deshalb dann mal auf FreeBSD 6.0 übergegangen und habe in der loader.conf per sys acpi angeschaltet - dann lief alles ganz ordentlich. Musste aber später (weil der 6.0 nach einem Update nicht übersetzen wollte) auf 5.4 / 5.5 zurück.

Ganz anfangs gab es auch mal Fehlerausgaben wie aufgehängte CPU2 oder CPU4 - dachte da auch an HW Problem. Obgleich Intel Server Board und Intel CPU wollte das BIOS die CPUs noch nicht erkennen. Offenbar lag es aber am FreeBSD, denn nach einem Update ging alles wie gewünscht.

da es ein remote gewartetes System ist, kann ich auch nicht einfach mal ein BIOS Update ausprobieren o.ä. Dinge... schade...

Interessant ist, das es offenbar eine ganze lange Zeit über Monate problemlos lief.

Aktuell ist es ein
5.5-PRERELEASE FreeBSD 5.5-PRERELEASE

Meine Bootausgabe kann ich beim nächsten Restart mal posten - finde die in den aktuellen Logs gerade nicht (wohl vers. gelöscht...).

Gibt es generell einen Weg als root Prozesse zu töten? habe hier in einem anderen Thread ähnliches gelesen - dort wartet der prozess offenbar auf I/O (im state D) - was ist denn, wenn der I/O dann nie kommt - bin ich / ist er dann aufgeschmissen, wie man so schön dazu sagt? Habe hier noch nicht auf den Proc-State tiefer geachtet - werde ich mal tun, wenn wieder auftritt und ps hierher posten...

Lohnt sich ev. wieder ein Wechsel auf ein 6.0? Als Produktivsystem wollte ich das eigentlich nicht - hatte aber moit dem 6 bisher doch bessere Erfahrungen gemacht (bis auf temp. Übersetzungsfehler)...

Gibt es ev. Open Source Tools, mit denen ich RAM und/oder CPUs ev. auch i.L. Betrieb zumindest auf die wichtigsten Funktionen prüfen kann? Hast Du da ev. etwas bestimmtes im Hinterkopf (Du sagtest ja CPU o.ä.)? Kann ich das irgendwie debuggen (kernel debug ist aus wg. performance)?

Warum aber trifft es immer wieder exakt die selben Anwendungen ("verrechnet" er sich dort durch Zufall an den seltenen selben Datenkonstellationen bzw. nur damit "klappern die richtigen Flipflops oder wie...)?

 

[MrFixit]

Der Prozess ist nicht kill-bar, wenn er noch in einem syscall "haengt" und somit sein Signal nicht verarbeiten kann (oder so aehnlich). Meistens ist das eben der Fall, wenn I/O haengt. Verwendest du Quotas?

6.0 kann helfen, vielleicht auch nicht. Ich wuerde es erstmal mit einem UP-Kernel probieren.

 

[niels]

Danke für den Tipp,

aber was thehell ist ein UP Kern (ein Neuerer?)?

Stimmt, Quten habe ich verwendet - kann ich ja mal ausmachen, weil nicht drauf zwingend angewiesen vorübergehend (meine User am Gerät "benehmen" sich bisher recht gut......~ß.)

Wie komme ich an den ev. syscall (lsof?)? Ist auch schon vorgekommen, das ich in auch anderen laufenden shells zwar was eintippen kann - aber dann statt der Befehlsantwort / Ausgabe nix mehr kommt und die konsole steht - Rest des systems läuft teils weiter - nur neue Logins remote sind auch nicht machbar, weil kein login kommt (verbindung ja - aber kein Login o. shell nach login...). Alles recht komisch. Dachte erst auch an Hardware, weil BSD ja eigentlich doch sooo stabil sein sollte - glaube das aber net so zweifelsfrei...

 

[MrFixit]

aber was thehell ist ein UP Kern (ein Neuerer?)?

UP = Uniprocessor, im Vergleich zu SMP. Wenn nur ein Thread laeuft, dann ist die Wahrscheinlichkeit eines Deadlocks geringern, koennte also Helfen.

Stimmt, Quten habe ich verwendet - kann ich ja mal ausmachen, weil nicht drauf zwingend angewiesen vorübergehend (meine User am Gerät "benehmen" sich bisher recht gut......~ß.)

AHA! 5.x hat einen bekannten Deadlock bei der Verwendung von Quotas, der wurde inzwischen in RELENG_6 behoben, es kann also sehr gut sein, dass dein Problem mit 6.1 verschwinden wird. Ist definitiv einen Versuch wert!

Wie komme ich an den ev. syscall (lsof?)? Ist auch schon vorgekommen, das ich in auch anderen laufenden shells zwar was eintippen kann - aber dann statt der Befehlsantwort / Ausgabe nix mehr kommt und die konsole steht - Rest des systems läuft teils weiter - nur neue Logins remote sind auch nicht machbar, weil kein login kommt (verbindung ja - aber kein Login o. shell nach login...).

Solche Symptome deuten eben darauf hin, dass kein I/O mehr stattfinden kann, weil irgendwas verklemmt ist. Passiert mir oefter mit NFS-Mounts, wenn ich die Verbindung beende, ohne vorher zu umounten.

Alles recht komisch. Dachte erst auch an Hardware, weil BSD ja eigentlich doch sooo stabil sein sollte - glaube das aber net so zweifelsfrei...

*BSD hat genauso Fehler wie jedes andere Stueck Software auch...