Grund für reboot feststellen?

[Exxter]

Hallo,

es kam zwei mal vor, dass mein Debian stable Server ohne mein Zutun rebootet wurde. Es war kein Benutzer. Das Wichtigste ist wohl die Meldung exiting on signal 15. aus der messages. Doch was hat den Reboot verursacht? "last -d10" zB. sagt vom letzten Reboot:

Code: Alles auswählen

reboot   system boot  0.0.0.0          Thu Feb 23 07:01 - 08:46  (01:44)

Dh. für mich, es war ein Dienst - oder ein Angreifer der seine Spuren verwischt hat.

Auf der Kiste läuft eine weiteres Debian stable 64bit unter KVM. Die zwei 500GB Platten sind ein Softraid. Kernel ist ein Eigenbau mit grsecurity.

Habt ihr eine Idee?

Hier noch die 3 wichtigsten Logs aus der Zeitspanne kurz vor und nach dem Reboot.

Code: Alles auswählen

/var/log/kern.log

Feb 23 06:55:06 SERVER kernel: [778713.746224] IN=eth0 OUT= MAC=00.00.00.00.00.00.00.00.00.00dc:03:08:00 SRC=xxx.xxx.xxx.136 DST=xxx.xxx.xxx.211 LEN=56 TOS=0x00 PREC=0x00 TTL=114 ID=
46662 DF PROTO=ICMP TYPE=3 CODE=3 [SRC=xxx.xxx.xxx.211 DST=xxx.xxx.xxx.136 LEN=64 TOS=0x00 PREC=0x00 TTL=228 ID=53948 DF PROTO=UDP SPT=24103 DPT=53 LEN=44 ]
Feb 23 06:56:14 SERVER kernel: [778781.856540] kvm [18308]: vcpu0, guest rIP: 0xffffffff812d637c unhandled rdmsr: 0xc001100d
Feb 23 06:58:26 SERVER kernel: [778913.677768] IN=eth0 OUT= MAC=00.00.00.00.00.00.00.00.00.00dc:03:08:00 SRC=xxx.xxx.xxx.48 DST=xxx.xxx.xxx.211 LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=41
548 DF PROTO=TCP SPT=57986 DPT=636 WINDOW=0 RES=0x00 RST URGP=0
Feb 23 06:58:26 SERVER kernel: [778913.715352] IN=eth0 OUT= MAC=00.00.00.00.00.00.00.00.00.00dc:03:08:00 SRC=xxx.xxx.xxx.48 DST=xxx.xxx.xxx.211 LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=41
549 DF PROTO=TCP SPT=57986 DPT=636 WINDOW=0 RES=0x00 RST URGP=0
Feb 23 06:59:05 SERVER kernel: [778952.808767] QNX4 filesystem 0.2.3 registered.
Feb 23 06:59:05 SERVER kernel: [778953.027079] fuse init (API version 7.25)
Feb 23 07:02:00 SERVER kernel: [    0.000000] Linux version 4.8.8-grsec-dasc (root@SERVER.de) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Thu Nov 17 14:54:21 CET 2016
Feb 23 07:02:00 SERVER kernel: [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.8.8-grsec-dasc root=UUID=ee00fd20-dd9f-4957-920f-b24cf214aa10 ro vconsole.keymap=de-latin1 co
nsole=tty0 console=ttyS0,57600
Feb 23 07:02:00 SERVER kernel: [    0.000000] x86/fpu: Legacy x87 FPU detected.
Feb 23 07:02:00 SERVER kernel: [    0.000000] x86/fpu: Using 'eager' FPU context switches.
Feb 23 07:02:00 SERVER kernel: [    0.000000] e820: BIOS-provided physical RAM map:
Feb 23 07:02:00 SERVER kernel: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable

Code: Alles auswählen

/var/log/syslog

Feb 23 06:57:01 SERVER postfix/qmgr[1501]: 98F67E80918: removed
Feb 23 06:58:26 SERVER kernel: [778913.677768] IN=eth0 OUT= MAC=00.00.00.00.00.00.00.00.00.00dc:03:08:00 SRC=xxx.xxx.xxx.48 DST=xxx.xxx.xxx.211 LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=41548 DF PROTO=TCP SPT=57986 DPT=636 WINDOW=0 RES=0x00 RST URGP=0
Feb 23 06:58:26 SERVER kernel: [778913.715352] IN=eth0 OUT= MAC=00.00.00.00.00.00.00.00.00.00dc:03:08:00 SRC=xxx.xxx.xxx.48 DST=xxx.xxx.xxx.211 LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=41549 DF PROTO=TCP SPT=57986 DPT=636 WINDOW=0 RES=0x00 RST URGP=0
Feb 23 06:59:05 SERVER kernel: [778952.808767] QNX4 filesystem 0.2.3 registered.
Feb 23 06:59:05 SERVER kernel: [778953.027079] fuse init (API version 7.25)
Feb 23 06:59:05 SERVER systemd[1]: Mounting FUSE Control File System...
Feb 23 06:59:05 SERVER systemd[1]: Mounted FUSE Control File System.
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sda1: part of software raid array
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sda2: is active swap
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sda3: part of software raid array
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sdb1: part of software raid array
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sdb2: is active swap
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sdb3: part of software raid array
Feb 23 06:59:08 SERVER systemd[1]: Started Synchronise Hardware Clock to System Clock.
Feb 23 06:59:08 SERVER systemd[1]: Stopping Session 4681 of user daniel.
Feb 23 06:59:08 SERVER systemd[1]: Stopping Session 3 of user daniel.
Feb 23 06:59:08 SERVER systemd[1]: Stopping system-systemd\x2dfsck.slice.
Feb 23 06:59:08 SERVER systemd[1]: Removed slice system-systemd\x2dfsck.slice.
Feb 23 06:59:08 SERVER systemd[1]: Stopping Virtual Machine and Container Registration Service...
Feb 23 06:59:08 SERVER systemd[1]: Stopping User Manager for UID 1002...
Feb 23 06:59:08 SERVER systemd[1]: Stopping Mail Transport Agent.
Feb 23 06:59:08 SERVER systemd[1]: Stopped target Mail Transport Agent.
Feb 23 06:59:08 SERVER systemd[1]: Stopping Graphical Interface.
Feb 23 06:59:08 SERVER systemd[1]: Stopped target Graphical Interface.
Feb 23 06:59:08 SERVER systemd[1]: Stopping Entropy daemon using the HAVEGE algorithm...
Feb 23 06:59:08 SERVER systemd[1]: Stopping Multi-User System.
Feb 23 06:59:08 SERVER systemd[1]: Stopped target Multi-User System.
Feb 23 06:59:08 SERVER systemd[1]: Stopping LSB: Start/stop sysstat's sadc...
Feb 23 06:59:08 SERVER systemd[1]: Stopping LSB: Firewall fuer ip-v4...
Feb 23 06:59:08 SERVER systemd[1]: Stopping LSB: daemon to balance interrupts for SMP systems...
Feb 23 06:59:08 SERVER systemd[1]: Stopping LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)...
Feb 23 06:59:08 SERVER systemd[1]: Stopping LSB: Starts or stops the xinetd daemon....
Feb 23 06:59:08 SERVER systemd[1]: Stopping LSB: Apache2 web server...
Feb 23 06:59:08 SERVER systemd[1]: Stopping LSB: Postfix Mail Transport Agent...
Feb 23 06:59:08 SERVER systemd[1]: Stopping LSB: coturn TURN Server...
Feb 23 06:59:09 SERVER systemd[1]: Stopping LSB: Start/stop fail2ban...
Feb 23 06:59:09 SERVER systemd[1]: Stopping LSB: Start NTP daemon...
Feb 23 06:59:09 SERVER systemd[1]: Stopping LSB: SNMP agents...
Feb 23 06:59:09 SERVER systemd[1]: Stopping Suspend Active Libvirt Guests...
Feb 23 06:59:09 SERVER systemd[1]: Stopping Regular background program processing daemon...
Feb 23 06:59:09 SERVER systemd[1]: Stopping vnStat network traffic monitor...
Feb 23 06:59:09 SERVER systemd[1]: Stopping Self Monitoring and Reporting Technology (SMART) Daemon...

Code: Alles auswählen

/var/log/messages

Feb 23 06:58:26 rigel kernel: [778913.715352] IN=eth0 OUT= MAC=00.00.00.00.00.00.00.00.00.00dc:03:08:00 SRC=xxx.xxx.xxx.48 DST=xxx.xxx.xxx.211 LEN=40 TOS=0x00 PREC=0x00 TTL=58 ID=41549 DF PROTO=TCP SPT=57986 DPT=636 WINDOW=0 RES=0x00 RST URGP=0
Feb 23 06:59:05 SERVER kernel: [778952.808767] QNX4 filesystem 0.2.3 registered.
Feb 23 06:59:05 SERVER kernel: [778953.027079] fuse init (API version 7.25)
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sda1: part of software raid array
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sda2: is active swap
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sda3: part of software raid array
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sdb1: part of software raid array
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sdb2: is active swap
Feb 23 06:59:06 SERVER os-prober: debug: /dev/sdb3: part of software raid array
Feb 23 06:59:12 SERVER rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="721" x-info="http://www.rsyslog.com"] exiting on signal 15.
Feb 23 07:02:00 SERVER rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="723" x-info="http://www.rsyslog.com"] start
Feb 23 07:02:00 SERVER kernel: [    0.000000] Linux version 4.8.8-grsec-dasc (root@SERVER.de) (gcc version 4.9.2 (Debian 4.9.2-10) ) #1 SMP Thu Nov 17 14:54:21 CET 2016
Feb 23 07:02:00 SERVER kernel: [    0.000000] Command line: BOOT_IMAGE=/vmlinuz-4.8.8-grsec-dasc root=UUID=ee00fd20-dd9f-4957-920f-b24cf214aa10 ro vconsole.keymap=de-latin1 console=tty0 console=ttyS0,57600
Feb 23 07:02:00 SERVER kernel: [    0.000000] x86/fpu: Legacy x87 FPU detected.
Feb 23 07:02:00 SERVER kernel: [    0.000000] x86/fpu: Using 'eager' FPU context switches.
Feb 23 07:02:00 SERVER kernel: [    0.000000] e820: BIOS-provided physical RAM map:
Feb 23 07:02:00 SERVER kernel: [    0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009efff] usable
Feb 23 07:02:00 SERVER kernel: [    0.000000] BIOS-e820: [mem 0x000000000009f000-0x000000000009ffff] reserved
Feb 23 07:02:00 SERVER kernel: [    0.000000] BIOS-e820: [mem 0x00000000000e4000-0x00000000000fffff] reserved
Feb 23 07:02:00 SERVER kernel: [    0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000ddfaffff] usable

[pferdefreund]

Das mit dem 15 ist es wohl nicht. Das ist nur die Mitteilung, dass - wer auch immer dem rsyslogd gesagt hat, "du kanns Schluss machen".
Ist nur das sigterm.
Ich würde bei sowas grundsätzlich erst mal mit memtest anfangen. Kaputtes RAM kann sowas verursachen.

[Exxter]

Gute Idee, mache ich nächstes WE gleich mal. Danke!

Obwohl, wenn es der RAM wäre, würde er sich dann normal herunterfahren und neu starten?

[gbotti]

Ich würde bei sowas grundsätzlich erst mal mit memtest anfangen. Kaputtes RAM kann sowas verursachen.

Ich würde auch erst einen memtest machen. Jedoch denke ich bei RAM-Problemen eher an Freeze oder KernelPanic.

Zuverlässig könntest du nur sagen dass jemand eingebrochen ist wenn du Beispielsweise per IDS die Dateien monitoren würdest. Eventuell war auch ein Stromausfall / eine Spannungsschwankung an dem reboot schuld. Hast du eine USV angeschlossen?

Möglicherweise hat das System auch beim reboot einen logrotate der wtmp-Datei unter /var/log durchgeführt. Schau mal nach ob es da mehrere gibt. Ausgeben kannst du eine ältere Datei dann Beispielsweise mit 'last -f /var/log/wtmp.1'.

Bei APC USVs hatte ich übrigens mal das Problem dass ein Firmwarefehler dazu geführt hat dass sie die Outlets immer wieder kurz abgeschalten hat weil sie dachte dass die Akkus leer sind.

Eventuell macht auch das Netzteil Probleme. Wie alte ist das denn? Ich hatte schon mal das Problem mit aufgeblähten Kondensatoren in einem Netzteil wo der Server in unregelmäßigen abständen einfach neu gestartet wurde und dann geweint hat dass er nicht ordentlich heruntergefahren wurde.

[gbotti]

Obwohl, wenn es der RAM wäre, würde er sich dann normal herunterfahren und neu starten?

Welche Software läuft denn da nativ drauf? Ich hatte mal einen Linux-Server zu Hause auf dem ich vdr installiert hatte. Bei irgend einem Update wurde dann eine Funktion eingeführt die den Server in den Hibernate schicken sollte sofern VDR nichts zu tun hat. Das hat bei mir zu reboots geführt.

Hat jemand physikalisch Zugriff auf den Server, also kommt jemand an die Tastatur oder KVM? Vielleicht wurde STRG+ALT+Entf gedrückt und somit der reboot ausgelöst. Da würde das deaktivieren der Routine helfen.

[Exxter]

Der Server steht bei Strato. Ich habe gerade mal geschaut, die Festplatten liefen beide schon 59828 Stunden, fast 7 Jahre! Also könnte alternde Hardware durchaus das Problem sein, wenn der Rest des Systems auch so alt ist
Auf dem Ding läuft einiges, NextCloud, OTRS, KVM, etliche Webanwendungen, FTP- und Mail-Server usw.

[Exxter]

Hallo,

nur um das Thema abzuschliessen, ich habe gerade herausgefunden woran die reboots lagen, es waren die Unattended-Upgrades. In der

/etc/apt/apt.conf.d/50unattended-upgrades

war folgendes eingestellt:

Code: Alles auswählen

// Automatically reboot *WITHOUT CONFIRMATION* if
//  the file /var/run/reboot-required is found after the upgrade
Unattended-Upgrade::Automatic-Reboot "true";

[gbotti]

Na wenigstens kann man das Verhalten unter Linux / Debian abstellen.

[pferdefreund]

Bei Open Source kann man im Regelfall immer was drehen - muss aber dann auch selber weiterpflegen.