spontaner reboot?

[ueckermann]

Hallo Forum,

gestern hat meine Debian-Kiste mal spontan ge-rebootet ohne das ich etwas gemacht hätte:

Code: Select all

Jul  2 20:09:07 p15122077 -- MARK --
Jul  2 20:29:07 p15122077 -- MARK --
Jul  2 20:43:21 p15122077 syslogd 1.4.1#10: restart.
Jul  2 20:43:21 p15122077 kernel: klogd 1.4.1#10, log source = /proc/kmsg started.
Jul  2 20:43:21 p15122077 kernel: Inspecting /boot/System.map-2.4.18-bf2.4
Jul  2 20:43:21 p15122077 kernel: Loaded 19387 symbols from /boot/System.map-2.4.18-bf2.4.
Jul  2 20:43:21 p15122077 kernel: Symbols match kernel version 2.4.18.
Jul  2 20:43:21 p15122077 kernel: Loaded 6 symbols from 1 module.
Jul  2 20:43:21 p15122077 kernel: Linux version 2.4.18-bf2.4 (root@mizar) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 Sun Jun 8 23:58:27 UTC 2003
Jul  2 20:43:21 p15122077 kernel: BIOS-provided physical RAM map:
Jul  2 20:43:21 p15122077 kernel:  BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
Jul  2 20:43:21 p15122077 kernel:  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Jul  2 20:43:21 p15122077 kernel:  BIOS-e820: 0000000000100000 - 000000000f7f0000 (usable)
Jul  2 20:43:21 p15122077 kernel:  BIOS-e820: 000000000f7f0000 - 000000000f7f3000 (ACPI NVS)
usw...

Ein normaler Reboot sieht so aus:

Code: Select all

Jul  3 10:42:24 p15122077 -- MARK --
Jul  3 10:56:02 p15122077 authdaemond.mysql: authdaemon: modules="authmysql", daemons=5 
Jul  3 10:56:06 p15122077 kernel: Kernel logging (proc) stopped.
Jul  3 10:56:06 p15122077 kernel: Kernel log daemon terminating.
Jul  3 10:56:06 p15122077 exiting on signal 15
Jul  3 10:56:57 p15122077 syslogd 1.4.1#10: restart.
Jul  3 10:56:57 p15122077 kernel: klogd 1.4.1#10, log source = /proc/kmsg started.
Jul  3 10:56:57 p15122077 kernel: Inspecting /boot/System.map-2.4.18-bf2.4
Jul  3 10:56:58 p15122077 kernel: Loaded 19387 symbols from /boot/System.map-2.4.18-bf2.4.
Jul  3 10:56:58 p15122077 kernel: Symbols match kernel version 2.4.18.
Jul  3 10:56:58 p15122077 kernel: Loaded 6 symbols from 1 module.
Jul  3 10:56:58 p15122077 kernel: Linux version 2.4.18-bf2.4 (root@mizar) (gcc version 2.95.4 20011002 (Debian prerelease)) #1 Sun Jun 8 23:58:27 UTC 2003
Jul  3 10:56:58 p15122077 kernel: BIOS-provided physical RAM map:
usw...

Kenn t vielleicht einer von euch die Ursache oder das Phänomen?

Grüße,

Nico

[sfeni]

Hab das gleiche Problem... Allerdings passiert das bei mir meist nachts um kurz nach 4, nachdem mein Backup auf den anderen Server kopiert wurde.
Während dem Backup würde ich es ja verstehen, aber direkt danach...

[dea]

Wenn's ein etwas älterer rootie ist und Du Deine Netzwerkkarte im promiscuous mode zu laufen hast, kann es sein, das ein "Nachbar" über das Konfigurationsmenü einen Reset seiner Kiste angefpordert hat.

Der geht dann als Broadcast raus (funktioniert ähnlich wie WOL) und Deine Büxe nimmt das dann dank promiscuous mode auch ernst und rebootet. Das sieht dann so aus wie Du gepostet hast (1. Ausschnitt).

Wenn Deine Netzwerkkarte nicht im promiscuous mode läuftkäme als augenfällige Alternative noch Software Watchdog in Frage- aber ich glaube nicht, dass Du das hast, sonst wüsstest Du warum Dein Server rebootet.

[sfeni]

Also ich habe einen neuen rooty.

[ueckermann]

hmm..

erstmal danke für die Antwort. ifconfig gibt das hier aus und mein rootie ist einer von den neuen:

Code: Select all

p15122077:~# ifconfig 
eth0      Link encap:Ethernet  HWaddr 00:40:63:C3:68:4F  
          inet addr:217.160.178.115  Bcast:217.160.178.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:102 errors:0 dropped:0 overruns:0 frame:0
          TX packets:100 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100 
          RX bytes:19271 (18.8 KiB)  TX bytes:11545 (11.2 KiB)
          Interrupt:15 Base address:0xe000 

grüße,

nico

[dea]

hmm - sieht nicht so aus, als wäre der promiscuous mode aktiviert ... ntop hast Du/habt ihr auch nicht im Einsatz? So war's nämlich mal bei mir - seitdem kein ntop mehr ...

Komischkomischkomisch ....

[ueckermann]

Code: Select all

bash: ntop: command not found

;-)

[mutombo]

vielleicht das böse via-rhine problem ?

[captaincrunch]

Was sagt bei dir ein

Code: Select all

cat /proc/sys/kernel/panic

?

[ueckermann]

Code: Select all

0

grüße,

nico

[captaincrunch]

OK, dann kannst du wenigstens einen Reboot aufgrund einer Kernel-Panic ausschließen ... :?

[sfeni]

Und was heißt das???

Code: Select all

p00000000:~# cat /proc/sys/kernel/panic
30
p00000000:~#

[ueckermann]

naja, solange das jetzt nicht täglich passiert ist es ja auch weiter kein problem. vielleicht findet sich die ursache ja in dem 1und1-seitigen rescuesystem und da ist irgendwas passiert...

grüße,

nico

[dea]

WO finde ich denn genauere Informationen über /proc/sys ? In den Sourcen hab' ich nichts gefunden, man sysctl hat auch nichts gebracht - bin mit meinem Latein am Ende ...

[captaincrunch]

@Sfeni :
In /proc/sys/kernel/panic kenne ich bisher nur zwei Werte : 0 und 1.

Die 0 besagt, dass bei einer Kernel-Panic das System angehalten wird, und du (wenn du vor der Konsole sitzt) per Migic SysRQ-Key den fehler debuggen könntest.

Beim Wert von 1 rebootet der Kernel selbständig das System, wenn eine Kernel-Panic auftritt.
Ich weiß zwar nicht, was bei einem Wert > 1 passiert, gehe aber davon aus, dass die Kernel-Entwickler sinnigerweise jeden Wert > 0 dazu abfragen, also sollte auch bei "30" die Kiste im Notfall rebooten, was bei Rooties natürlich ziemlich sinnig wäre.

@dea :
Infos darüber findest du teilweise unter /usr/src/linux/Documentation, ansonsten ist http://kernelnewbies.org/ inkl. zugehörigem IRC-Channel (in dem sich oft auch "bekannte" Namen rumtreiben) eine gute Anlaufstelle. Die Linux-Kernel Mailinglist (LKML) ist zwar ein bisschen Overkill dafür, ich persönlich finde sie aber aüßerst informativ ...

[sfeni]

@CaptainCrunch
Wo kann ich denn darüber was finden, was dann die 30 bei mir bedeutet?

[captaincrunch]

Keine Ahnung. Ich kenne dein System nicht, und weiß auch nicht wer da was wie aufgesetzt hat. Was die 30 bedeutet habe ich versucht, im letzten Posting zu erklären, wie die da hin kommt kann ich dir beim besten Willen nicht sagen.

Ich würde den Wert jedenfalls (z.B. per echo 1 > /proc/sys/kernel/panic ) in 1 ändern, da dur sonst hart über das Konfigurationsmenü rebooten müsstest, wenn wirklich einmal eine Panic auftritt.

[rootmaster]

könnte freilich auch ein hardware-prob sein, zb netzteil ;)

"back to the roots"

[rootmaster]

@CaptainCrunch
Wo kann ich denn darüber was finden, was dann die 30 bei mir bedeutet?

der wert in "/proc/sys/kernel/panic" ist imho die zeit (in sek.) nach der kernelpanic, nach der ein reboot versucht wird

"back to the roots"

[sfeni]

@CaptainCrunch
Wo kann ich denn darüber was finden, was dann die 30 bei mir bedeutet?

der wert in "/proc/sys/kernel/panic" ist imho die zeit (in sek.) nach der kernelpanic, nach der ein reboot versucht wird

"back to the roots"

Danke rootmaster =)

[captaincrunch]

OK, ich hab's mit der Boot-time-Option verwechselt :oops: . Ganz genau steht's aber in /usr/src/linux/Documentation/sysctl/kernel.txt :

panic:

The value in this file represents the number of seconds the
kernel waits before rebooting on a panic. When you use the
software watchdog, the recommended setting is 60.

Da gibt's auch genauere Infos über sonstige Dinge aus /proc/sys.

[dea]

Danke Captain! Hätt' ich selber drauf kommen können, aber nein, ich muss ja unbedingt gleich in den Sourcen schauen ... *g*

Wegen der Zahl in /proc/sys/panic habe ich in /usr/src/linux/Documentation/filesystems/proc.txt folgendes gefunden:

panic
-----

The value in this file represents the number of seconds the kernel waits
before rebooting on a panic. When you use the software watchdog, the
recommended setting is 60. If set to 0, the auto reboot after a kernel panic
is disabled, which is the default setting.

Interessant, interessant ... :)