Regelmäßiger ungewollter Neustart von Rootserver

manfredu

manfredu

New Member
Hallo,

suche Vorschläge zur Ursachen- und Lösungsfindung: Unser gemieteter Rootserver bootet ca. alle drei Stunden ohne erkennbaren Grund. In den Logs ist nichts zu finden. Nach einem Hardwarecheck war 18 Tage Ruhe und dann ging es plötzlich wieder los. Jetzt haben wir die Hardware tauschen lassen (bis auf die Platten), aber auch das hat nichts gebracht.

Es handelt sich um ein Dual-Core-System mit AMD Opteron(tm) Processor 1216 und 6 GB RAM. Ubuntu 8.04 LTS, Kernel 2.6.24-23-generic. Plesk Control Panel-Version psa v8.6.0_build86080722.00 os_Ubuntu 8.04

Wir benutzen das System wie vorkonfiguriert von S4Y, haben lediglich noch SpamDyke eingebunden.

Danke, Manfred
 
djrick said:
Was steht denn in den Server logs?
Click to expand...

Nichts ausser dem Restart-Hinweis und den üblichen Bootmeldungen. Nichts Sichtbares davor, was auf den Grund hindeuten könnten. Auch keine sonstigen gleichen Ereignisse davor.

djrick said:
Ist das System vielleicht kompromittiert?
Click to expand...

Was könnte das sein? Wie überprüft man das man besten?


Hier die Zeiten, irgendwie regelmäßig:
Code: 
Mar 31 06:51:37 oslo074 syslogd 1.5.0#1ubuntu1: restart. (Normaler Logfile restart ohne reboot)
Apr  1 06:46:52 oslo074 syslogd 1.5.0#1ubuntu1: restart. (Normaler Logfile restart ohne reboot)
Apr  2 06:30:53 oslo074 syslogd 1.5.0#1ubuntu1: restart. (Normaler Logfile restart ohne reboot)
Apr  3 06:49:33 oslo074 syslogd 1.5.0#1ubuntu1: restart. (Normaler Logfile restart ohne reboot)
Apr  4 06:41:41 oslo074 syslogd 1.5.0#1ubuntu1: restart. (Normaler Logfile restart ohne reboot)
Apr  5 04:05:18 oslo074 syslogd 1.5.0#1ubuntu1: restart. ??? Hier gings los!
Apr  5 06:36:15 oslo074 syslogd 1.5.0#1ubuntu1: restart. 
Apr  5 06:47:08 oslo074 syslogd 1.5.0#1ubuntu1: restart. (Normaler Logfile restart ohne reboot)
Apr  5 09:03:46 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  5 11:35:58 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  5 14:22:27 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  5 17:03:47 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  5 19:39:56 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  5 22:15:48 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  6 00:52:38 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  6 03:25:21 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  6 05:54:21 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  6 08:30:54 oslo074 syslogd 1.5.0#1ubuntu1: restart.  (Server Neustart wg. Hardwarecheck)
Apr  6 11:35:10 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  6 14:50:45 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  6 17:27:34 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  6 20:01:34 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  6 22:42:24 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  7 01:11:23 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  7 03:41:54 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  7 06:06:28 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  7 06:31:13 oslo074 syslogd 1.5.0#1ubuntu1: restart.  (Normaler Logfile restart?)
Apr  7 08:36:05 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  7 11:38:11 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  7 14:46:29 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  7 17:41:31 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  7 20:14:08 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  7 23:07:01 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  8 01:37:38 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  8 04:05:37 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  8 06:33:49 oslo074 syslogd 1.5.0#1ubuntu1: restart.  (Normaler Logfile restart?)
Apr  8 09:12:32 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  8 12:33:26 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  8 15:32:15 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  8 18:33:28 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  8 21:49:42 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  9 00:37:00 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  9 03:20:12 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  9 05:48:27 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  9 06:48:59 oslo074 syslogd 1.5.0#1ubuntu1: restart.  (Normaler Logfile restart?)
Apr  9 08:28:13 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  9 08:41:53 oslo074 syslogd 1.5.0#1ubuntu1: restart.  (Kernelaktualisierung, manueller Reboot)
Apr  9 11:43:09 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  9 15:10:08 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  9 17:31:49 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr  9 17:43:03 oslo074 syslogd 1.5.0#1ubuntu1: restart. (Server down wg. Hardwaretausch)
Apr 10 09:59:08 oslo074 syslogd 1.5.0#1ubuntu1: restart. (Server up wg. Hardwaretausch)
Apr 10 12:30:35 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr 10 15:09:38 oslo074 syslogd 1.5.0#1ubuntu1: restart.
Apr 10 17:54:24 oslo074 syslogd 1.5.0#1ubuntu1: restart.
 
Last edited by a moderator:
Naja das sind bislang nur syslogd restarts keine Serverreboots.... :)

Nur mal so ins Blaue geraten: Poste mal die Ausgabe von
Code: 
uptime
 
djrick said:
Naja das sind bislang nur syslogd restarts keine Serverreboots.... :)

Nur mal so ins Blaue geraten: Poste mal die Ausgabe von
Code: 
uptime
Click to expand...

Ne, ne, schön wärs.

Meine Benutzer beschweren sich über die Unterbrechungen, ich habe selber schon Posts in unserem internen Forum verloren, weil der Webserver plötzlich hing und meine SSH-Session raucht auch ab. Und uptime kenne ich auch ;-)

Ich habe die Zeiten ja gekennzeichnet, wo es nur syslogd Restarts waren. Zu den anderen Zeiten gibt es die ganzen Bootmeldungen. Nur eben nichts davor, was den Neustart ausgelöst haben könnte. Ich bin heute noch mal sämtliche Logs systematisch durchgegangen.

# uptime
19:35:02 up 1:42, 1 user, load average: 0.32, 0.79, 0.87
 
Von einem Runterfahren kann ich nichts feststellen. Sieht mehr wie ein Reset aus:

Code: 
Apr 10 15:09:38 myserver kernel: [   55.773884] Adding 999992k swap on /dev/sda2.  Priority:-1 extents:1 across:999992k
Apr 10 15:09:38 myserver kernel: [   55.803481] Adding 999992k swap on /dev/sdb2.  Priority:-2 extents:1 across:999992k
Apr 10 15:09:38 myserver kernel: [   56.165459] EXT3 FS on md1, internal journal
Apr 10 15:29:38 myserver -- MARK --
Apr 10 15:49:38 myserver -- MARK --
Apr 10 16:09:38 myserver -- MARK --
Apr 10 16:29:38 myserver -- MARK --
Apr 10 16:49:38 myserver -- MARK --
Apr 10 17:09:38 myserver -- MARK --
Apr 10 17:29:38 myserver -- MARK --
Apr 10 17:49:38 myserver -- MARK --
Apr 10 17:54:24 myserver syslogd 1.5.0#1ubuntu1: restart.
Apr 10 17:54:24 myserver kernel: Inspecting /boot/System.map-2.6.24-23-generic
Apr 10 17:54:25 myserver kernel: Loaded 28522 symbols from /boot/System.map-2.6.24-23-generic.
Apr 10 17:54:25 myserver kernel: Symbols match kernel version 2.6.24.
Apr 10 17:54:25 myserver kernel: Loaded 10141 symbols from 61 modules.
Apr 10 17:54:25 myserver kernel: [    0.000000] Initializing cgroup subsys cpuset
Apr 10 17:54:25 myserver kernel: [    0.000000] Initializing cgroup subsys cpu
Apr 10 17:54:25 myserver kernel: [    0.000000] Linux version 2.6.24-23-generic (buildd@crested) (gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu3)) #1 SMP Wed Apr 1 21:43:24 UTC 2009 (Ubuntu 2.6.24-23.52-generic)
Apr 10 17:54:25 myserver kernel: [    0.000000] Command line: root=UUID=f0d507c7-735e-4f29-8dbc-96d9d248a4ce ro vga=ext
Apr 10 17:54:25 myserver kernel: [    0.000000] BIOS-provided physical RAM map:
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 0000000000000000 - 000000000009dc00 (usable)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 000000000009dc00 - 00000000000a0000 (reserved)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 00000000000cc000 - 0000000000100000 (reserved)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 0000000000100000 - 000000007fff0000 (usable)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 000000007fff0000 - 0000000080000000 (reserved)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 0000000080000000 - 00000000cfee0000 (usable)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 00000000cfee0000 - 00000000cfef2000 (ACPI data)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 00000000cfef2000 - 00000000cff7f000 (ACPI NVS)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 00000000cff80000 - 00000000d0000000 (reserved)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
Apr 10 17:54:25 myserver kernel: [    0.000000]  BIOS-e820: 0000000100000000 - 00000001b0000000 (usable)
Apr 10 17:54:25 myserver kernel: [    0.000000] end_pfn_map = 1769472
Apr 10 17:54:25 myserver kernel: [    0.000000] DMI present.
Apr 10 17:54:25 myserver kernel: [    0.000000] ACPI: RSDP signature @ 0xFFFF8100000F79B0 checksum 0
Apr 10 17:54:25 myserver kernel: [    0.000000] ACPI: RSDP 000F79B0, 0024 (r2 PTLTD )
u.s.w.
 
Aber wenn ich ihn manuell runterfahre, sehe ich auch nicht viel:

Code: 
Apr  9 08:40:46 myserver exiting on signal 15
Apr  9 08:41:53 myserver syslogd 1.5.0#1ubuntu1: restart.
Apr  9 08:41:53 myserver kernel: Inspecting /boot/System.map-2.6.24-23-generic
u.s.w.

Also kann ich die Frage nicht klar beantworten
 
Allerdings deuten die folgenden Meldungen beim Booten meiner Meinung nach auf kein sauberes Runterfahren hin:

Code: 
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: WARNING: mysqlcheck has found corrupt tables
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
Apr  9 11:43:22 myserver /etc/mysql/debian-start[4723]: warning  : 1 client is using or hasn't closed the table properly
 
Schonmal testweise den Cron-Daemon gestoppt?
Vielleicht wird irgendein Befehl ausgeführt, der zwar keinen Reboot, aber dafür einen Kernel-Panic auslösen könnte.
Bin mir aber auch nicht sicher, ob dabei zumindest nach dem Neustart ein Eintrag im Log hinterlassen wird.

Bietet dein Hoster eine Reset-Funktion über das Controlpanel an?
Ändere mal das Passwort dazu, vielleicht hat das ja irgendwer herausbekommen und schickt da zum Spaß Resetanforderungen drüber.

Du kannst auch das Tool 'atop' auf dem Server laufen lassen und mit
# atop 5 -w dateiname.log
ein Logfile aller laufenden Prozesse erzeugen lassen.
Nach einem Reboot guckst du dir auch mit atop das aufgezeichnete Logfile an und kannst bis zu der Stelle spulen, kurz bevor der Server den Neustart hingelegt hat. Vielleicht taucht ja dort ein Prozess auf, der sonst nicht in der Liste steht oder zumindest besonders aktiv wird.
 
Was ist denn das für ein Modell?
Ich bin Techniker bei S4Y und da ja jede Hardwarekonfiguration bekannte oder weniger bekannte Bugs produzieren kann (sei es nur ein defektes Netzteil) könnte ich vielleicht weiterhelfen.

Ich denke ich weiß schon um welchen Server es sich handelt aber das darf ich leider nicht öffentlich bekanntgeben.

Also wenn ich nur das Modell wüsste könnte man hinterher auf offiziellem Weg den Fehler eingrenzen und ausmerzen.
 
Verwirrter said:
Was ist denn das für ein Modell?
Ich bin Techniker bei S4Y und da ja jede Hardwarekonfiguration bekannte oder weniger bekannte Bugs produzieren kann (sei es nur ein defektes Netzteil) könnte ich vielleicht weiterhelfen.

Ich denke ich weiß schon um welchen Server es sich handelt aber das darf ich leider nicht öffentlich bekanntgeben.

Also wenn ich nur das Modell wüsste könnte man hinterher auf offiziellem Weg den Fehler eingrenzen und ausmerzen.
Click to expand...
Es ist ein Dual-Core-System mit AMD Opteron(tm) Processor 1216 und 6 GB RAM unter Ubuntu 8.04 LTS. Wäre klasse, wenn das Problem gelöst werden könnte. Der Hostname oslo074 ist ja schon genannt worden...
 
Last edited by a moderator:
Am 17.04. gegen 1:xx nachts war der letzte Reboot, danach war Ruhe.

Bis heute morgen 03.05 um 3:55. Seitdem geht das Spiel wieder los.

Beim letzten mal fing es am 05.04. um 4:05 an.

Das ist doch zum Verrücktwerden.
 
Bin der Sache näher gekommen. Nachdem Booten startet md1_resync. Irgendwann steht der dann bei 99% und dann erfolgt ein Reset und das Spiel geht wieder von vorne los.

Code: 
#cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sdb3[0] sda3[1]
      464663936 blocks [2/2] [UU]
      [===============>.....]  resync = 79.1% (367643648/464663936) finish=36.3min speed=44487K/sec

md0 : active raid1 sdb1[0] sda1[1]
      97536 blocks [2/2] [UU]

unused devices: <none>
Code: 
# mdadm --detail /dev/md1
/dev/md1:
        Version : 00.90.03
  Creation Time : Tue Jan  6 17:20:31 2009
     Raid Level : raid1
     Array Size : 464663936 (443.14 GiB 475.82 GB)
  Used Dev Size : 464663936 (443.14 GiB 475.82 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 1
    Persistence : Superblock is persistent

    Update Time : Mon May  4 14:41:03 2009
          State : active, resyncing
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

 Rebuild Status : 78% complete

           UUID : 029cf4c9:25a67d89:7792c71e:7dc17aa4
         Events : 0.713

    Number   Major   Minor   RaidDevice State
       0       8       19        0      active sync   /dev/sdb3
       1       8        3        1      active sync   /dev/sda3

Bedeutet dies, das eine Platte getauscht werden muss und wenn ja, welche? Oder 'spinnt' nur der Resync?
 
Hmm was mich stutzig macht: Ne zeitlang lief es doch.,... der hat doch wohl kaum nen halben Monat gebraucht zum synchen von 500 GB, oder? ;)

Vielleicht solltest du mal die Dateisysteme / Festplatten checken. Überwachst du die SMART Werte?
 
Doch der Resync hat solange gebraucht. Weil er immer bei 99% abgestürzt ist und dann nach dem Reset von vorne angefangen hat.

Irgendwann ist er wohl doch mal durchgekommen und dann war dann erstmal Ruhe, bis mdadm dann irgendwann doch mal wieder gemerkt hat, dass was mit der Platte nicht stimmt und erneut einen Resync gestartet hat. Damit ging die Schleife dann wieder los...

Habe jetzt die defekte Platte mit smartctl rausgefunden und bis zum Austausch auf faulty gesetzt. Damit gibt es keine resyncs mehr und damit auch keine ständigen Neustarts. :-)

Komisch, dass der resync nicht mit einer sauberen Fehlermeldung geendet ist.
 
You must log in or register to reply here.
Back
Top