Netfabrik Basic: Broken libc? [war: VZ Quotas geändert?]
Hallo Forum,
ich habe den kleinsten VS (5 Euro) bei Netfabrik unter SuSE 9.3. Letzten November habe ich mich schon ans Forum gewandt, weil numfiles mit 1680 sehr niedrig eingestellt waren. Freundlicherweise wurde das Limit im Dezember auf 3008 angehoben und seit dem lief der Server zu meiner vollen Zufriedenheit. Ganz selten bin ich mal gegen die Memorybarriere gerannt, jedoch ohne Auswirkungen. Die Uptime war die selbe wie die des Hostes, nämlich 51 Tage!
Doch nun treten seit Montag, 12.03., , massive Probleme mit der dcachesize auf! Ohne dass ich etwas an der Config geändert habe, laufe ich jetzt ständig gegen dieses Limit. Davor liefen alle Dienste wochenlang durch, ohne dass ich nur einen Blick auf den Server werfen musste, jetzt kommen nach einem Reboot nicht mal mehr alle hoch. Die ersten Anzeichen finden sich am 12.03. um 16:26 in der mail.err.
Die Symptome:
1. Trotz keinerlei Configänderung gehen nicht mehr alle Dienste gleichzeitig. Apache 2 schafft es gar nicht mehr, wenn Postfix und Co. schon gestartet wurden. Die Logs zeigen dann Fehler wie nicht gefundene Dateien etc. Ich hatte sogar schon den Fall, dass mir ls nur das halbe Verzeichnis ausgab. Hier mal ein Beispiel aus dem PHP5-Log:
2. Clamd gibt folgenden Fehler beim Start ab und läuft gar nicht mehr:
3. Nachdem mir die Fehler am Dienstag aufgefallen waren, habe ich die fehlenden Dienste neu gestartet. Bisher zeigte mir ein "netstat -tap" auch immer die Namen der Prozesse mit an. Nach dem Fixingversuch waren nur noch die Namen der ohne Absturz durchgelaufenen Prozesse zu sehen, die neu gestarteten hatten nur noch einen Strich. Jetzt, nach etlichen Serverreboots, findet sich überall nur noch ein Strich, kein einziger Prozessname wird mehr angezeigt.
4. Ein Check auf geänderte Files mit "find / -mtime -6" bringt mir folgenden Fehler:
Sonst stimmen die Änderungen mit den Erwartungen überein.
5. Gut denke ich, versuche ich mal einen fsck für ReiserFS. Also will ich die Reiserprogramme über Yast installieren. Doch was passiert? Jetzt will dazu Yast immer die libc in einer 64-Bit-Version haben, welche sich nicht im Repositorium vom SuSE befindet. Bei mir ist nur libc in 32 Bit installiert, und wie gesagt, lief das bisher tadellos. Könnte es sein, dass Virtuozzo selbst mit einem 64-Bit-Kernel läuft (was mir uname sagt), die virtualisierten Childs aber 32 Bit sind?
6. Postfix meldet jetzt sowas in den Logs:
7. Bei einem Reboot werden jetzt immer in die Runlevel neue Links S10vzquota nach /etc/init.d/vzquota eingetragen. Das mag schon immer so gewesens ein, nur habe ich auch schon seit Januar 2006 überall S11vzquota drin stehen.
Irgendwie habe ich das Gefühl, dass das gar nicht mehr mein Server ist. :-(
In den Logs finden sich wie immer auch massenhaft Wörterbuchattacken auf SSH, aber dort geht nur Public/Private-Key zum Einloggen. Nur kann man einen VServer als Einbrecher so verändern, dass die Timestamps wie vorher erscheinen und auch sonst keine Anzeichen zu erkennen sind, d.h. dass verräterische Prozesse und Ports versteckt werden können? An den Kernel kommt man ja nicht dran.
Vielleicht liest das ja der Herr Brömme von Intergenia und kömmte mal auf meinem Knoten nachschauen. Irgendwie bin ich nicht bereit, für 2 Euro die Hotline anzurufen, wenn ich selbst nichts an meinem Server geändert habe. Auch die 10 Euro für eine Neuinstallation will ich nicht unbedingt ausgeben. ;-)
Ich habe eher den Eindruck, dass man meinen Server im laufenden Betrieb von 32 Bit auf 64 Bit verschoben hat oder dass mein virtuelles ReiserFS die Flocke macht. Denn die Probleme von Postfix und Clamd liegen nicht an der dcachesize, weil sich der failcnt beim Starten dieser Dienste nicht erhöht.
Sonst kann ich nur fragen, ob jemand ähnliche Probleme erlebt, oder ob man mir Tips geben kann, wie ich einen Einbruch ausschliesse.
MfG
Andreas
Hallo Forum,
ich habe den kleinsten VS (5 Euro) bei Netfabrik unter SuSE 9.3. Letzten November habe ich mich schon ans Forum gewandt, weil numfiles mit 1680 sehr niedrig eingestellt waren. Freundlicherweise wurde das Limit im Dezember auf 3008 angehoben und seit dem lief der Server zu meiner vollen Zufriedenheit. Ganz selten bin ich mal gegen die Memorybarriere gerannt, jedoch ohne Auswirkungen. Die Uptime war die selbe wie die des Hostes, nämlich 51 Tage!
Doch nun treten seit Montag, 12.03., , massive Probleme mit der dcachesize auf! Ohne dass ich etwas an der Config geändert habe, laufe ich jetzt ständig gegen dieses Limit. Davor liefen alle Dienste wochenlang durch, ohne dass ich nur einen Blick auf den Server werfen musste, jetzt kommen nach einem Reboot nicht mal mehr alle hoch. Die ersten Anzeichen finden sich am 12.03. um 16:26 in der mail.err.
Code:
Version: 2.5
uid resource held maxheld barrier limit failcnt
2066086: kmemsize 2861020 4235457 5644968 6209464 0
lockedpages 0 8 302 302 0
privvmpages 41702 52390 77672 85456 0
shmpages 640 1312 16305 16305 0
dummy 0 0 0 0 0
numproc 32 42 96 96 0
physpages 15554 29140 0 2147483647 0
vmguarpages 0 0 14604 2147483647 0
oomguarpages 15554 29441 17750 2147483647 0
numtcpsock 8 14 152 152 0
numflock 10 13 168 183 0
numpty 1 1 12 12 0
numsiginfo 0 8 256 256 0
tcpsndbuf 75008 196896 1133248 2214592 0
tcprcvbuf 131072 265200 1133248 2214592 0
othersockbuf 159392 271800 524572 922896 0
dgramrcvbuf 0 33000 524572 524572 0
numothersock 104 139 198 198 0
dcachesize 645354 774225 751593 774141 548
numfile 1142 1763 3008 3008 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
dummy 0 0 0 0 0
numiptent 10 10 32 32 0Die Symptome:
1. Trotz keinerlei Configänderung gehen nicht mehr alle Dienste gleichzeitig. Apache 2 schafft es gar nicht mehr, wenn Postfix und Co. schon gestartet wurden. Die Logs zeigen dann Fehler wie nicht gefundene Dateien etc. Ich hatte sogar schon den Fall, dass mir ls nur das halbe Verzeichnis ausgab. Hier mal ein Beispiel aus dem PHP5-Log:
Code:
[16-Mar-2007 12:36:24] PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/extensions/zlib' - /usr/lib/php5/extensions/zlib: cann
ot open shared object file: Cannot allocate memory in Unknown on line 0
Code:
Fri Mar 16 12:38:32 2007 -> ERROR: fstat(): socket descriptor gone
Fri Mar 16 12:38:32 2007 -> ERROR: Main socket gone: fatal
Fri Mar 16 12:38:32 2007 -> Shutting down the main socket.
Fri Mar 16 12:38:32 2007 -> Closing the main socket.3. Nachdem mir die Fehler am Dienstag aufgefallen waren, habe ich die fehlenden Dienste neu gestartet. Bisher zeigte mir ein "netstat -tap" auch immer die Namen der Prozesse mit an. Nach dem Fixingversuch waren nur noch die Namen der ohne Absturz durchgelaufenen Prozesse zu sehen, die neu gestarteten hatten nur noch einen Strich. Jetzt, nach etlichen Serverreboots, findet sich überall nur noch ein Strich, kein einziger Prozessname wird mehr angezeigt.
4. Ein Check auf geänderte Files mit "find / -mtime -6" bringt mir folgenden Fehler:
Code:
find: WARNING: Hard link count is wrong for /proc/vz: this may be a bug in your filesystem driver. Automatically turning on find's -noleaf option. Earlier results may have failed to include directories that should have been searched.5. Gut denke ich, versuche ich mal einen fsck für ReiserFS. Also will ich die Reiserprogramme über Yast installieren. Doch was passiert? Jetzt will dazu Yast immer die libc in einer 64-Bit-Version haben, welche sich nicht im Repositorium vom SuSE befindet. Bei mir ist nur libc in 32 Bit installiert, und wie gesagt, lief das bisher tadellos. Könnte es sein, dass Virtuozzo selbst mit einem 64-Bit-Kernel läuft (was mir uname sagt), die virtualisierten Childs aber 32 Bit sind?
6. Postfix meldet jetzt sowas in den Logs:
Code:
Mar 16 13:03:58 heptamer postfix/cleanup[9490]: fatal: fstat flow pipe write descriptor: Value too large for defined data type
Mar 16 13:03:59 heptamer postfix/smtpd[9474]: fatal: unable to connect to the public cleanup service
Mar 16 13:11:42 heptamer postfix/cleanup[24039]: fatal: fstat flow pipe write descriptor: Value too large for defined data type
Mar 16 13:11:43 heptamer postfix/smtpd[24035]: fatal: unable to connect to the public cleanup service
Mar 16 13:30:14 heptamer postfix/cleanup[3462]: fatal: fstat flow pipe write descriptor: Value too large for defined data type
Mar 16 13:30:15 heptamer postfix/smtpd[3436]: fatal: unable to connect to the public cleanup service
Mar 16 13:30:28 heptamer postfix/sendmail[6010]: fatal: root(0): unable to execute /usr/sbin/postdrop -r: Success7. Bei einem Reboot werden jetzt immer in die Runlevel neue Links S10vzquota nach /etc/init.d/vzquota eingetragen. Das mag schon immer so gewesens ein, nur habe ich auch schon seit Januar 2006 überall S11vzquota drin stehen.
Irgendwie habe ich das Gefühl, dass das gar nicht mehr mein Server ist. :-(
In den Logs finden sich wie immer auch massenhaft Wörterbuchattacken auf SSH, aber dort geht nur Public/Private-Key zum Einloggen. Nur kann man einen VServer als Einbrecher so verändern, dass die Timestamps wie vorher erscheinen und auch sonst keine Anzeichen zu erkennen sind, d.h. dass verräterische Prozesse und Ports versteckt werden können? An den Kernel kommt man ja nicht dran.
Vielleicht liest das ja der Herr Brömme von Intergenia und kömmte mal auf meinem Knoten nachschauen. Irgendwie bin ich nicht bereit, für 2 Euro die Hotline anzurufen, wenn ich selbst nichts an meinem Server geändert habe. Auch die 10 Euro für eine Neuinstallation will ich nicht unbedingt ausgeben. ;-)
Ich habe eher den Eindruck, dass man meinen Server im laufenden Betrieb von 32 Bit auf 64 Bit verschoben hat oder dass mein virtuelles ReiserFS die Flocke macht. Denn die Probleme von Postfix und Clamd liegen nicht an der dcachesize, weil sich der failcnt beim Starten dieser Dienste nicht erhöht.
Sonst kann ich nur fragen, ob jemand ähnliche Probleme erlebt, oder ob man mir Tips geben kann, wie ich einen Einbruch ausschliesse.
MfG
Andreas
Last edited by a moderator:
Wann gibt es denn da Abhilfe?