RootForum Community

Ich geb's auf ... ich bin inzwischen völlig ratlos.

Unser Server läuft seit über einem Jahr eigentlich fast völlig problemlos. Nacht's lassen wir die Kiste immer ein paar Aufgaben automatischmachen (Datensicherung, Traffic ermitteln, u.ä.) und dann per shutdown -r neu booten. Auch das klappt immer einwandfrei. Bis heute morgen. Da kam er nicht wieder hoch.

Erste Idee: irgendwas ziwchen gestern abend und heute morgen hat die Kiste zum abschmieren gebracht und dabei das Filesystem so versaut, daß der automatische fsck nicht will und damit bootet er nicht durch.

Also ... Rescue System aktiviert und manuell ran an die Sache. Aber ... oh Wunder ... beide Partitionen (hda1 und hda3) sind clean.

In /va/log sehen messages und boot.msg ebenfalls ganz normal aus. Das letzte was dort protokolliert ist sind die Dinge vom Runterfahren/Rebootversuch d.h. der Wechsel auf init 6 ... sieht alles absolut normal aus.

Also ... nächste Idee: irgendwas mit dem MBR und/oder Kernel ist nicht ok.

Also per lilo diverses probiert, von einfachem Neuschreiben des MBR über Uninstall/Neuinstall des Bootloaders über Reaktivieren eines älteren gesicherten Kernels bis zum installieren eines "sauberen" kernel-2.4.18 Archivs vom updateserver.

Nix. Bei keinem der Versuche tut sich irgendwas an den Filesystemen. Die sind immer sauber, nix Neues in den /var/log Protokollen da bleiben nur die alten Sachen von heute morgen/gestern. Im /etc/init.d/rc hatte ich auch mal ein touch/sync untergebracht, um zu sehen, ob er da vorbeikommt, aber falls er überhaupt von der Platte bootet, dann kommt er da definitiv nicht mehr an.

Mir fällt nichts mehr ein. Jedenfalls nichts was ich noch testen könnte. Das einzige was mir überhaupt noch in den Sinn kommt, ist daß er überhaupt nicht von der Platte bootet, weil irgendwas im BIOS versaut ist oder so ... aber das scheint mir doch auch arg unwahrscheinlich. Aber ansonsten macht die Kiste ja einen ordentlichen Eindruck. Sie bootet das Rescue-System ... von dort kann ich die Partionionen prüfen (und sie sind wie gesagt clean) und mounten und darauf sieht auch alles soweit ich das beurteilen kann ok aus.

Irgendjemand irgendwelche Vorschläge? Ich bin sozusagen "verzweifelt". :(

Das einzige was mir dazu einfällt:

Ich bin ratlos warum ihr den Server jeden Tag neustartet.
Das ist sowas von Sinnfrei und schadet auch noch der Hardware (Festplatte).

Giffi

Logan wrote:Im /etc/init.d/rc hatte ich auch mal ein touch/sync untergebracht, um zu sehen, ob er da vorbeikommt, aber falls er überhaupt von der Platte bootet, dann kommt er da definitiv nicht mehr an.

Dann bleibt die Maschine in einem anderen Teil der /etc/inittab hängen. Bei mir wäre das z.B. /etc/init.d/rcS oder /sbin/sulogin. Hast eventuell du den initdefault in der inittab geändert? Bei mir steht der auf 2.

Also ... Rescue System aktiviert und manuell ran an die Sache. Aber ... oh Wunder ... beide Partitionen (hda1 und hda3) sind clean.

Hast du "nur" ein fsck /dev/hda[13] gemacht, oder (wie es in dem Fall korrekt wäre) ein fsck -f /dev/hda[13] ?

CaptainCrunch wrote:Hast du "nur" ein fsck /dev/hda[13] gemacht, oder (wie es in dem Fall korrekt wäre) ein fsck -f /dev/hda[13] ?

Hmm ... Du meinst "Scheiss drauf, daß sie sauber unmounted wurden, könnte ja trotzdem was mau sein"? Ist'n Punkt ...

So ... habe forcierten fsck gerade nachgeholt ... sieht alles sauber aus:

rescue:~# fsck -f /dev/hda1
fsck 1.27 (8-Mar-2002)
e2fsck 1.27 (8-Mar-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda1: 111/65536 files (0.0% non-contiguous), 3098/65536 blocks
rescue:~# fsck -f /dev/hda3
fsck 1.27 (8-Mar-2002)
e2fsck 1.27 (8-Mar-2002)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/hda3: 98264/4898816 files (0.9% non-contiguous), 2406990/9787601 blocks

Partitionen scheinen also doch ok zu sein.

olaf.dietsche wrote: Dann bleibt die Maschine in einem anderen Teil der /etc/inittab hängen. Bei mir wäre das z.B. /etc/init.d/rcS oder /sbin/sulogin. Hast eventuell du den initdefault in der inittab geändert? Bei mir steht der auf 2.

Nö ... da haben wir nie was dran gedreht. Steht derzeit auf

# default runlevel
id:3:initdefault:

was meiner Meinung nach auch der normale default ist.

Als allererstes scheint mir inittab /etc/init.d/boot anzuziehen ... mal sehen, vielleicht verwige ich mich da nochmal mit einem touch /tmp/foo und einem sync. Das scheint mir aber auch so ziemlich die frühestste Stelle zu sein, an der ich überhaupt was derartiges machen kann.

Was mich ja imme rnoch brennend interessiert ist, ab wann irgendwo (z.B. /var/log/boot.msg) was protokolliert wird. Ich finde wie gesagt überhaupt keine Anzeichen dafür, daß überhaupt ein Bootversuch von der Platte unternommen wird ...

warum bootet man einen LINUX-server jede nacht?? das bleibt auch mir ein rätsel. :roll:
das doch kein windoof-server der immerwieder neu gebootet werden muß!

Mann Leute ... wenn ihr nix vernünftiges zu sagen habt, dann könnt Ihr auch einfach schweigen oder ggf. einen eigenen Thread aufmachen, um zu diskutieren, wie sinnig oder unsinnig es ein mag regelmäßig zu booten und wie sehr ein regelmäßiger Warmstart die Hardware (Platte) belastet.

Ja ... man muß einen Linux-Server sicher nicht soooft neu booten wie einen Windoof-Gurke, aber auch er steht nach einen Neustart wieder schön frisch initialisiert da und es gab verschiedenen Gründe, warum das so eine schöne einfache Lösung ist und man sich dadurch im Prinzip um nix kümmern muß.

Ich denke nicht, daß die regelmäßigen "sauberen" Neustarts der Grund für das vorliegende Problem sind. Schließlich sind es nur Warmstarts und nicht ein komplettes Powerdown bei dem die Platten zum Stillstand kommen und dann wieder hochbeschleunigen müssen, etc. Wäre es nicht jetzt duch den "normalen" Restart passiert, dann hätten wir das Problem ohne Zweifel beim nächsten Kernel-Update o.ä. gehabt und dann hätten wir vermutlich das Problem dort gesucht, wo es aber vermutlich nicht liegt.

Logan wrote:Schließlich sind es nur Warmstarts und nicht ein komplettes Powerdown bei dem die Platten zum Stillstand kommen und dann wieder hochbeschleunigen müssen, etc.

Eben nicht: siehe http://www.rootforum.org/forum/viewtopi ... 6&start=30

Giffi