Tinos bLog

S4F5

20080104: Syslogd hängt: killall -9 syslogd

Ein Phänomen wie ich es in über 20 Jahren Praxis noch nie erlebt habe.

Ich musste den syslog-Server killen und restarten damit er das System nicht weiter verklemmt:

Der Syslog-Server hat /var/log/auth.log derart verklemmt, so dass weder tail -f auf die Datei ging, noch kamen normale syslog-Meldungen durch, d. h. sobald eine Meldung Richtung auth.log gehen sollte blieb der /dev/log socket hängen. Dadurch war weder ein Login per ssh noch ein "su -" möglich. Wie gut dass auf einer Mühle noch ein Root-Prompt zu der Maschine rumdümpelte über den ich mich am toten Syslogd vorbeischummeln konnte ohne ihn zu berühren.

Durch dieses Problem hatten sich über 100 Cron-Jobs verklemmt, weil sie ihren "su" oder sonstige Nachrichten nicht mehr durchbrachten. Anfangs war nur alles in Richtung auth.log betroffen, aber kurz bevor ich den Fix anbrachte fiel so gut wie alles das auf Syslog basiert aus, darunter Cron, weil gar nichts mehr durchkam.

Interessant war, dass nach dem Neustart vom Syslog alles wieder lief, bis auf eine SSH-Session die sich beim Login verklemmt hatte. Anscheinend verträgt sshd nicht, wenn man den syslog-Stream killt während ssh versucht zu loggen. Auch die Verklemmung auf die Datei beseitigte sich.

Der Kill war mit -9 notwendig. Außerdem brauchte es eine ganze Weile bis der durchkam. Offensichtlich war einiges an Resourcen durcheinandergebracht.

Maschinenhintergrund

Auf der Maschine läuft Ubuntu 6.06 LTS Server, der letzte Reboot liegt 289 Tage zurück, ein neueres Kernel wäre verfügbar, wird aber nicht eingespielt da dafür ein Reboot notwendig wäre und vom aktuellen Kernel keine Gefahr ausgeht.

Die Maschine hat nur 2 GB RAM, da auf ihr ein Java-Prozess läuft (FreenetProject) der über 1.5 GB RAM verbraucht, ist die Maschine leider mit RAM hoffnungslos unterversorgt. (An sich ist Java auf nur 800 MB eingestellt, aber da es eine 64-Bit-Maschine ist scheint Java den RAM doppelt zu belegen, und mit weniger als 800 MB fährt Freenet nicht mehr hoch.)

Die Context-Switch-Rate fällt selten unter die 10000er-Marke, es werden über 2000 Blocks pro Sekunde von der Platte geladen und ich habe durchaus heftige Page-Storms im Swapspace. Seufz. Eine 8 GB Maschine wäre nicht schlecht, die sind aber einfach noch nicht im richtigen Preissegment. 4 GB wäre gerade mal ein schlechter Anfang, da ich irgendwann vorhabe, parallel Freenet 0.7 laufen zu lassen, denn dass Freenet 0.5 tot wäre, das kann ich noch lange nicht sehen.

Ich habe auch diese typischen Fehler
Laut Linux-Kernel-Liste sind die zwar harmlos, da es sich um unzerstückelte Pre-Allocations handelt die das Kernel nicht befriedigen muss, aber die nerven gewaltig da sie den Syslog zudröhnen. Laut Kernel-Liste kommen die sehr selten. Ich würde sagen, bei mir sind die extrem häufig, oft mehrfach pro Sekunde (offensichtlich triggert wegen der angespannten Lage bei mir der Code im Kernel häufiger also woanders).