seit kurzen Zeigt der Server ein "komisches" verhalten. Er läuft zwar noch d.h Pingpar und die Dienste antworten zwar noch auf einen Connect brechen dann aber die Verb. ab. Genau zu diesem Zeitpunkt hören ALLE Logs einfach auf. Das ganze ist jetzt genau 2 Mal innerhalb von 3 Tagen passiert. Der Server ist sonst noch nie abgeschmiert.
Debian 3.0_r2
Rootforums CC 2.4.26_ipv6 Kernel lief voher auch schon ein weilchen
May 16 05:00:01 vadp /USR/SBIN/CRON[7927]: (root) CMD (wget -q http://localhost/split/split_tsc.php -O /var/www/html/split/muell)
May 16 05:00:01 vadp PAM_unix[7925]: (cron) session opened for user root by (uid=0)
May 16 05:00:01 vadp /USR/SBIN/CRON[7928]: (root) CMD (/etc/webmin/webalizer/webalizer.pl /home/apache_user/logs/access_log)
May 16 05:00:01 vadp PAM_unix[7926]: (cron) session opened for user root by (uid=0)
May 16 05:00:01 vadp /USR/SBIN/CRON[7929]: (root) CMD (yasuc)
May 16 05:00:01 vadp /USR/SBIN/CRON[7930]: (root) CMD (/etc/webmin/webalizer/webalizer.pl /var/log/apache/access_log)
May 16 05:00:02 vadp PAM_unix[7924]: (cron) session closed for user root
May 16 05:00:03 vadp yasuc[7929]: Transfer successful
May 16 05:00:03 vadp PAM_unix[7925]: (cron) session closed for user root
May 16 05:00:08 vadp PAM_unix[7926]: (cron) session closed for user root
May 16 05:00:18 vadp PAM_unix[7923]: (cron) session closed for user root
May 16 05:03:42 vadp init: Id "SV" respawning too fast: disabled for 5 minutes
May 16 05:08:43 vadp init: Id "SV" respawning too fast: disabled for 5 minutes
May 16 05:13:45 vadp init: Id "SV" respawning too fast: disabled for 5 minutes
May 16 05:15:01 vadp PAM_unix[8084]: (cron) session opened for user root by (uid=0)
May 16 05:15:01 vadp /USR/SBIN/CRON[8085]: (root) CMD (wget -q http://localhost/split/split_tsc.php -O /var/www/html/split/muell)
May 16 05:15:16 vadp PAM_unix[8084]: (cron) session closed for user root
May 16 05:18:46 vadp init: Id "SV" respawning too fast: disabled for 5 minutes
May 16 05:23:47 vadp init: Id "SV" respawning too fast: disabled for 5 minutes
May 16 05:28:48 vadp init: Id "SV" respawning too fast: disabled for 5 minutes
May 16 05:30:01 vadp PAM_unix[8212]: (cron) session opened for user root by (uid=0)
May 16 05:30:01 vadp /USR/SBIN/CRON[8213]: (root) CMD (wget -q http://localhost/split/split_tsc.php -O /var/www/html/split/muell)
May 16 05:30:16 vadp PAM_unix[8212]: (cron) session closed for user root
May 16 05:33:50 vadp init: Id "SV" respawning too fast: disabled for 5 minutes
May 16 05:37:01 vadp PAM_unix[8259]: (cron) session opened for user root by (uid=0)
May 16 05:37:01 vadp /USR/SBIN/CRON[8260]: (root) CMD (/usr/lib/AntiVir/antivir --update -q)
May 16 05:37:02 vadp antivir[8260]: AntiVir is up-to-date
May 16 05:37:02 vadp PAM_unix[8259]: (cron) session closed for user root
May 16 05:38:51 vadp init: Id "SV" respawning too fast: disabled for 5 minutes
May 16 05:43:52 vadp init: Id "SV" respawning too fast: disabled for 5 minutes
May 16 05:45:01 vadp PAM_unix[8352]: (cron) session opened for user root by (uid=0)
May 16 05:45:01 vadp /USR/SBIN/CRON[8353]: (root) CMD (wget -q http://localhost/split/split_tsc.php -O /var/www/html/split/muell)
May 16 05:45:16 vadp PAM_unix[8352]: (cron) session closed for user root
May 16 05:48:53 vadp init: Id "SV" respawning too fast: disabled for 5 minutes
Bus 0, device 0, function 0:
Host bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia] (rev 5).
Master Capable. Latency=8.
Prefetchable 32 bit memory at 0xe0000000 [0xe3ffffff].
Bus 0, device 1, function 0:
PCI bridge: VIA Technologies, Inc. VT8601 [Apollo ProMedia AGP] (rev 0).
Master Capable. No bursts. Min Gnt=12.
Bus 0, device 7, function 0:
ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 64).
Bus 0, device 7, function 1:
IDE interface: VIA Technologies, Inc. VT82C586B PIPC Bus Master IDE (rev 6).
Master Capable. Latency=32.
I/O at 0xe000 [0xe00f].
Bus 0, device 7, function 4:
Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 64).
IRQ 9.
Bus 0, device 13, function 0:
Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 16).
IRQ 15.
Master Capable. Latency=32. Min Gnt=32.Max Lat=64.
I/O at 0xec00 [0xecff].
Non-prefetchable 32 bit memory at 0xe7000000 [0xe70000ff].
Bus 1, device 0, function 0:
VGA compatible controller: Trident Microsystems CyberBlade/i1 (rev 106).
IRQ 11.
Master Capable. Latency=32.
Non-prefetchable 32 bit memory at 0xe5800000 [0xe5ffffff].
Non-prefetchable 32 bit memory at 0xe6000000 [0xe601ffff].
Non-prefetchable 32 bit memory at 0xe5000000 [0xe57fffff].
Könnte (neben allem anderen *g*) die Festplatte sein. Hast du diesbezüglich Warnungen in den Logs? Ich würde mal Smartmontools installieren (apt-get install smartsuite). Evtl. auch noch mbmon / lm-sensors.
Sascha wrote:Das ist afaik so ein seltsames Script in den alten 1&1 Images welches in der inittab eingetragen ist.
Auf einem Debian rooty ?. 1und1 hat da null mit zu tun
Ne das hat irgendwas mti Qmail zu tun. Steht ja hier irgenwo im Forum.
An die Platte dachte ich auch erst, aber im Logs ist 0 zu finden.
Schick denen den Log und die wechseln die Platte innerhalb von wenigen Stunden. Aber vorher ein Backup machen, 1&1 macht das nicht sondern du bekommst ein frisches Image.
Hm. Also hab bei einem Plattenschaden mal da angrufen und derartige Dinge vorgelesen und noch hinzugefügt das sich die platte auch mit Rescue Modus trotz fsck nicht mounten lässt und das hat problemlos geklappt, innerhalb von 2 Stunden hatte ich eine neue Platte.
Last edited by oxygen on 2004-05-26 13:28, edited 1 time in total.
Das Problem ist u.a auch das ich ab nächster Woche 2 Monate nicht an den Server kann. Nen Ersatzadmin ist zwar immer parat aber dieser kann bei einem Plattenschaden sicher nicht alles so wiederherstellen.
z.b Qmail mit Antivir und Spamassassin.
1und1 war auch auf der Kiste und hat selbst nachgesehen.
PS: Laut Telefonsupport ist der einzige Grund für einen Tausch der Platte nen I/O Fehler oder wenn garnixmehr geht.
Es könnte Leute geben, die sich hier im Forum, oder per google solche I/O Fehlermeldungen suchen würden und dann ihre eigenen Logs faken.
Denn falls die 1&1 Leute auf die Maschine schauen, sollen sie ja auch das richtige sehen.
Solch ein Vorgehen würde ich aber nie empfehlen, da es ja nicht ganz legal ist :!:
Thorsten wrote:Es könnte Leute geben, die sich hier im Forum, oder per google solche I/O Fehlermeldungen suchen würden und dann ihre eigenen Logs faken.
Denn falls die 1&1 Leute auf die Maschine schauen, sollen sie ja auch das richtige sehen.
Sollte einer von den 1&1 Mitarbeiter auf die Maschine schauen, würde er ja sehen, dass was im argen liegt.
