Hilfe bei Serverausfällen

[pocopelli]

Hallo zusammen,

wir betreiben einen Rootserver bei Hetzner. Dieser stürzt in letzter Zeit fast schon wöchentlich ab. Ich habe schon alle LogFiles (insbesondere /var/log/auth.log) durch, kann aber nichts erkennen. Mein Verdacht ist, daß sich ein Mitarbeiter per ssh in einem INternetcafe auf unseren Server eingeloggt hat, wobei eventuell Logindaten von dritten erkannt wurden. Daraufhin habe ich das Passwort geändert. Trotzdem gibt es Abstürze.

Hat jemand eine Idee, was man kann zwecks Fehlersuche / Abwendung von Abstürzen ? Jegliche Ideen, Hinweise, Einschätzungen etc. wären hilfreich.
Dank euch im voraus.

Gruß

Poc

[EdRoxter]

Was genau ist "abstürzen"? Ist er nicht mehr erreichbar? Geht Softreset? Oder funktioniert nur noch Hardreset?

[pocopelli]

... die Hardware muß über das Webinterface bei Hetzner neu gestartet werden. In /var/log/kern.log hab ich noch folgendes entdeckt:

Sep 18 11:27:21 localhost kernel: raid6: sse2x4 4543 MB/s
Sep 18 11:27:21 localhost kernel: raid6: using algorithm sse2x4 (4543 MB/s)
Sep 18 11:27:21 localhost kernel: md: raid6 personality registered for level 6
Sep 18 11:27:21 localhost kernel: md: raid5 personality registered for level 5
Sep 18 11:27:21 localhost kernel: md: raid4 personality registered for level 4
Sep 18 11:27:21 localhost kernel: md: raid10 personality registered for level 10
Sep 18 11:27:21 localhost kernel: Attempting manual resume
Sep 18 11:27:21 localhost kernel: EXT3-fs: INFO: recovery required on readonly filesystem.
Sep 18 11:27:21 localhost kernel: EXT3-fs: write access will be enabled during recovery.
Sep 18 11:27:21 localhost kernel: kjournald starting. Commit interval 5 seconds
Sep 18 11:27:21 localhost kernel: EXT3-fs: sda2: orphan cleanup on readonly fs
Sep 18 11:27:21 localhost kernel: ext3_orphan_cleanup: deleting unreferenced inode 20250633
Sep 18 11:27:21 localhost kernel: ext3_orphan_cleanup: deleting unreferenced inode 20250632
Sep 18 11:27:21 localhost kernel: ext3_orphan_cleanup: deleting unreferenced inode 20250631
Sep 18 11:27:21 localhost kernel: ext3_orphan_cleanup: deleting unreferenced inode 20250630
Sep 18 11:27:21 localhost kernel: ext3_orphan_cleanup: deleting unreferenced inode 20250629
Sep 18 11:27:21 localhost kernel: ext3_orphan_cleanup: deleting unreferenced inode 20250628
Sep 18 11:27:21 localhost kernel: EXT3-fs: sda2: 6 orphan inodes deleted
Sep 18 11:27:21 localhost kernel: EXT3-fs: recovery complete.
Sep 18 11:27:21 localhost kernel: EXT3-fs: mounted filesystem with ordered data mode.
Sep 18 11:27:21 localhost kernel: input: PC Speaker as /class/input/input1
Sep 18 11:27:21 localhost kernel: i2c_adapter i2c-0: nForce2 SMBus adapter at 0x5000
Sep 18 11:27:21 localhost kernel: i2c_adapter i2c-1: nForce2 SMBus adapter at 0x6000
Sep 18 11:27:21 localhost kernel: Adding 2096440k swap on /dev/sda1. Priority:-1 extents:1 across:2096440k
Sep 18 11:27:21 localhost kernel: EXT3-fs warning: checktime reached, running e2fsck is recommended
Sep 18 11:27:21 localhost kernel: EXT3 FS on sda2, internal journal
Sep 18 11:27:21 localhost kernel: loop: loaded (max 8 devices)
Sep 18 11:27:21 localhost kernel: device-mapper: ioctl: 4.7.0-ioctl (2006-06-24) initialised: dm-devel@redhat.com
Sep 18 11:27:21 localhost kernel: e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
Sep 18 11:27:21 localhost kernel: NET: Registered protocol family 10
Sep 18 11:27:21 localhost kernel: lo: Disabled Privacy Extensions
Sep 18 11:27:21 localhost kernel: IPv6 over IPv4 tunneling driver
Sep 18 11:27:32 localhost kernel: eth0: no IPv6 routers present

Deutet vielleicht auf kaputte Software hin. Keine Aknung.

[aquajo]

Falls jemand der 'mal root-Zugang hatte den server kompromittiert hat, könnte er ja auch andere Hintertüren eingebaut haben, so dass dieser verdacht durch eine Passwortänderung nicht zu beseitigen ist.

Evtl. ist auch die Hardware schuld, oder noch was anderes.

Ich würde erst einmal den Server intensiv überwachen (auch wer eingelogt ist, wie die Last ist usw.) und dann schauen ob man irgendwelche Muster erkennen kann.
Falls nicht würde ich die Hardware testen lassen.

[daemotron]

Dem Kernel mal noapic mitgeben - das hat meine H.-Kiste von ihrer Abstürzerei kuriert (wobei ich mir allerdings 100% sicher war, dass kein anderer dran rumgepfuscht hatte).

[pocopelli]

Danke für die Zahlreichen Antworten:

noapic scheint bei mir nicht zu laufen:

Debian-pre40-64-minimal:/var/log# dmesg | grep apic
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] disabled)
IOAPIC[0]: apic_id 2, version 3, address 0xfec00000, GSI 0-23
Debian-pre40-64-minimal:/var/log# dmesg | grep "Kernel command line"
Kernel command line: auto BOOT_IMAGE=Standardkernel ro root=802
Debian-pre40-64-minimal:/var/log#

Kann jemand mir als Dummy sagen, wie man noapic als Bootparameter
mitgibt ?

[daemotron]

Einfach "noapic" als Argument in die Kernel-Befehlszeile in der menu.lst (falls Bootloader == grub) hinten dranhängen. Wie's bei Lilo funktioniert => ich nix lilo, ich nix weiß

[thorsten]

in der lilo.conf gibt es auch eine append= Zeile.

Beim grub drückst du im Bootmenü einfach e für edit , gehst in die append-Zeile und drückst wieder e für edit.
Per b für boot bringst du die Kiste dann hoch.

.oO(Grub ist schon einfeines Stück Software)

[pocopelli]

Also wir nutzen lilo. Hier die Conf

boot=/dev/sda
root=/dev/sda2
delay=20
vga=normal
default=Standardkernel
image=/boot/vmlinuz
label=Standardkernel
read-only
initrd=/boot/initrd.img

Bevor ich hier "noapic reinsetze",müßte allerdings Klarheit haben, da? nichts kaputt geht und der Schritt auch reversibel ist. Was würde noapic liefern ? (Ich weiß ... dumm gefragt)

[pocopelli]

Hi,

ich hatte euren Tipp "noapic" in die lilo.conf einzutragen befolgt. Leider stürzt der Server trotzdem am Wochenende machmal ab. Gibt es hier ein empfehlenswerte Monitoringlösungen, die die Prozesse (besser als in /var/log/) mitloggen.

mir ist vollkommen unklar, warum der Server manchmal ausfällt. Ich hatte mir gedacht, die Ausgabe von "ps awux" alle 5 Minuten irgendwo hinzuschreiben,um überhaupt eine Ahnung zu bekommen, woran es liegen könnte. Ist vielleicht zu aktig? Habt ihr andere Ideen ? Eventuell liegt es auch an größeren Datentransfers.

Bin für jegliche Anregung zur Fehlereinkreisung / -Beseitigung dankbar.

Gruß

Poc

[cirox]

Du hast ja ne e100 drinnen? Das ist schon mal nicht Standard bei Hetzner und lässt genau den 3ware/Kernel/Realtek Bug ahnen.

So sieht das aus:

Code: Select all

boot=/dev/sda
root=/dev/sda5
delay=20
default=Standardkernel
append="noapic"

image=/boot/vmlinuz
	label=Standardkernel
	read-only
	initrd=/boot/initrd.img

Hast Du nach der Änderung auch "lilo" geschrieben in der Konsole?

Lass Dir mal wieder ne andere Netzwerkkarte einbauen und kompilier mal einen anderen Kernel. Du kannst natürlich auch einen neuen Server holen :)

[Joe User]

Du hast ja ne e100 drinnen? Das ist schon mal nicht Standard bei Hetzner und lässt genau den 3ware/Kernel/Realtek Bug ahnen.

Ähm, der e100 kommt von Intel, nicht Realtek.

[cirox]

Ich hätte noch dazuschreiben müssen, dass die Nürnberger auf Wunsch die Realtek Karte mit der Intel Karte austauschen, wegen diesem Bug. Das half bei mir aber gar nicht, ausser das danach gar keine Logeinträge mehr vorhanden waren, der Server aus dem Stand abgeschmiert ist und demzufolge der IRQ ? zur Festplatte weg war.

[Anonymous]

Hat sich geklärt. Daher nehme ich meinen Text hier wieder raus.

Ich habe aber immer noch die Frage: Wie verlässlich ist mbmon?
Kennt sich jemand damit im Detail aus?

Danke.

[cirox]

Anbieterwechsel ? -> Schwachfug :), jedenfalls im Billigpreissegment.

Boote doch die Kiste wie beschrieben, dann hört es auch auf. Vergiss den Befehl "lilo" nicht, wenn Du die config änderst. Ich denke zusätzlich, daß die neue Hardware das nicht macht.

PS: Der Server stürzt deswegen Sonntags immer ab, weil ihr da höchst wahrscheinlich den meisten Traffic auf eth0 habt.

[Anonymous]

Anbieterwechsel ? -> Schwachfug :), jedenfalls im Billigpreissegment.

Boote doch die Kiste wie beschrieben, dann hört es auch auf. Vergiss den Befehl "lilo" nicht, wenn Du die config änderst. Ich denke zusätzlich, daß die neue Hardware das nicht macht.

PS: Der Server stürzt deswegen Sonntags immer ab, weil ihr da höchst wahrscheinlich den meisten Traffic auf eth0 habt.

Nein, am Traffic liegt es mit Sicherheit nicht. Da der Traffic um die Absturzzeiten nie hoch war.

[daemotron]

Bei mir hingen die Abstürze mit erhöhter Festplattenaktivität zusammen. Größere rsync-Aktionen, Backups oder einfach nur herumkopieren einer größeren Datenmenge, und schon war Feierabend. Das war allerdings auf einer Maschine mit 3ware-Controller; auf Deinem Server hast Du offenbar Software-RAID laufen (falls nicht, unbedingt mal die RAID-Module deaktivieren).