Es kommt nicht selten vor, dass ein Linux-System unerwartet oder aus unbekannten Gründen neu startet. Die Ursachenforschung kann helfen, solche Vorfälle zu verhindern und ungeplante Ausfallzeiten zu vermeiden.
Es gibt verschiedene Wege, um herauszufinden, was den Neustart ausgelöst hat. In diesem Artikel werden wir diese Methoden beleuchten und erklären, wie Sie mit den verfügbaren Tools und Protokollen auf Ihrem Linux-System solche Szenarien analysieren können.
Überprüfung der Neustartzeitpunkte
Mit den Befehlen who und last können Sie den genauen Zeitpunkt des Systemneustarts ermitteln.
$ who -b
system boot 2021-02-13 20:51
$ last -x | head | tac
abhishek pts/0 192.168.1.16 Sat Feb 13 19:53 - 19:55 (00:02)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:54 (00:58)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 19:55 - 20:04 (00:08)
abhishek pts/0 192.168.1.16 Sat Feb 13 19:56 - 20:04 (00:07)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:54 (00:49)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:04 - 20:51 (00:46)
abhishek pts/0 192.168.1.16 Sat Feb 13 20:04 - 20:50 (00:46)
reboot system boot 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:03)
runlevel (to lvl 3) 3.10.0-1160.11.1 Sat Feb 13 20:51 - 20:54 (00:02)
abhishek pts/0 192.168.1.16 Sat Feb 13 20:51 still logged in
Analyse der Systemmeldungen
Die Systemmeldungen können zusätzliche Informationen zum diagnostizierten Neustart liefern.
Auf CentOS/RHEL-Systemen finden Sie diese Protokolle unter /var/log/messages, während sie bei Ubuntu/Debian-Systemen unter /var/log/syslog gespeichert werden. Mit dem Befehl tail oder einem Texteditor können Sie die relevanten Daten extrahieren.
Wie in den folgenden Protokollen zu sehen, weisen solche Einträge auf einen von einem Administrator oder Root-Benutzer initiierten Shutdown/Neustart hin. Diese Meldungen können je nach Betriebssystem und Art des Neustarts variieren. Die Systemprotokolle enthalten jedoch immer nützliche Informationen, auch wenn sie nicht immer eindeutig die Ursache bestimmen können.
Feb 13 19:56:20 centos7vm chronyd[637]: Source 72.30.35.89 replaced with 142.147.92.5
Feb 13 20:00:40 centos7vm chronyd[637]: Selected source 162.159.200.123
Feb 13 20:01:01 centos7vm systemd: Created slice User Slice of root.
Feb 13 20:01:01 centos7vm systemd: Started Session 2 of user root.
Feb 13 20:04:09 centos7vm systemd-logind: System is powering down.
Feb 13 20:04:09 centos7vm systemd: Closed LVM2 poll daemon socket.
Feb 13 20:04:09 centos7vm systemd: Stopped target Multi-User System.
Hier ist ein Befehl, um Systemprotokolle zu filtern:
sudo grep -iv ': starting|kernel: .*: Power Button|watching system buttons|Stopped Cleaning Up|Started Crash recovery kernel'
/var/log/messages /var/log/syslog /var/log/apcupsd*
| grep -iw 'recover[a-z]*|power[a-z]*|shut[a-z ]*down|rsyslogd|ups'
Die erfassten Ereignisse sind möglicherweise nicht immer eindeutig. Achten Sie auf Warnungen oder Fehler, die zu einem Systemabsturz oder Shutdown geführt haben könnten.
Überprüfung der Auditd-Protokolle
Auf Systemen, die auditd verwenden, ist dies ein guter Ort, um verschiedene Ereignisse mithilfe eines Suchwerkzeugs zu untersuchen. Mit dem folgenden Befehl können Sie die letzten beiden Einträge aus den Überwachungsprotokollen überprüfen:
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
Dieser Befehl zeigt die letzten zwei Shutdowns oder Neustarts an. Wenn ein SYSTEM_SHUTDOWN gefolgt von einem SYSTEM_BOOT gemeldet wird, ist alles in Ordnung. Werden jedoch zwei SYSTEM_BOOT-Zeilen hintereinander oder nur eine einzige SYSTEM_BOOT-Zeile angezeigt, wurde das System höchstwahrscheinlich nicht ordnungsgemäß heruntergefahren. Eine normale Ausgabe sollte wie folgt aussehen:
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_SHUTDOWN msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
$
Die folgende Ausgabe zeigt zwei aufeinanderfolgende SYSTEM_BOOT-Meldungen, was auf ein nicht ordnungsgemäßes Herunterfahren hindeuten könnte. Dies sollte jedoch mit Systemprotokollen verifiziert werden.
$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.852:8) : pid=621 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
----
type=SYSTEM_BOOT msg=audit(Saturday 13 February 2021 A.368:8) : pid=622 uid=root auid=unset ses=unset subj=system_u:system_r:init_t:s0 msg=' comm=systemd-update-utmp exe=/usr/lib/systemd/systemd-update-utmp hostname=? addr=? terminal=? res=success'
$
Analyse des Systemd-Journals
Um ein dauerhaftes Journal zu führen, sollten Sie ein persistentes systemd-Journal auf der Festplatte haben, da sonst die Protokolle bei einem Neustart verloren gehen. Dazu können Sie entweder die Änderungen in /etc/systemd/journald.conf vornehmen oder das Verzeichnis selbst mit folgenden Befehlen erstellen:
$ sudo mkdir /var/log/journal
$ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null
$ sudo systemctl -s SIGUSR1 kill systemd-journald
Optional können Sie das System neu starten, um mehr als einen Neustarteintrag im Journal zu erfassen, obwohl dies nicht erforderlich ist.
Verwenden Sie den folgenden Befehl, um die protokollierten Starts aus dem Journal aufzulisten:
$ journalctl --list-boots
Hier ist die Ausgabe von meinem Server:
$ journalctl --list-boots
-15 8a7c8034da804ebb9cb063a7553ed0bf Wed 2020-11-18 23:09:05 IST—Wed 2020-11-18 23:17:10 IST
-14 7bbb9542778a4057a91b9d22fcf91735 Wed 2020-11-18 23:17:22 IST—Wed 2020-11-18 23:20:08 IST
-13 f2ee8a61bf4c4f67a12e012855d8b1c3 Wed 2020-11-18 23:20:17 IST—Wed 2020-11-18 23:23:01 IST
-12 1277d19a959f4c33ba944a68c5874d2a Fri 2020-12-11 10:32:44 IST—Fri 2020-12-11 10:43:39 IST
-11 eb4ff97f112445888a5946d1155de1b8 Fri 2020-12-11 10:43:55 IST—Fri 2020-12-11 10:48:18 IST
-10 bf46eff3f9a344d2b28a03ffbf7fff32 Fri 2020-12-11 19:04:30 IST—Fri 2020-12-11 19:31:01 IST
-9 2acf08368667423c89086579f98efd82 Tue 2020-12-15 17:36:52 IST—Tue 2020-12-15 19:13:10 IST
-8 b826f223a67d454b94d4413678870f08 Sat 2020-12-19 00:31:54 IST—Sat 2020-12-19 00:44:52 IST
-7 011e1b29339041b0ae48bbb93fce792f Wed 2020-12-23 23:01:15 IST—Wed 2020-12-23 23:02:44 IST
-6 f41f5880572e4394938c6dcb4a8b683c Mon 2020-12-28 16:54:11 IST—Mon 2020-12-28 22:54:22 IST
-5 a2e638dc292a4db2b0a50dd442129c28 Tue 2020-12-29 17:02:16 IST—Tue 2020-12-29 19:39:38 IST
-4 f6c738df872a48d48daee1962727cca5 Wed 2020-12-30 19:09:30 IST—Wed 2020-12-30 19:20:23 IST
-3 c876e60ea371460b94e247b40270b18f Thu 2020-12-31 14:36:07 IST—Thu 2020-12-31 15:45:36 IST
-2 a23c70804ec243f7868c18737f4b7e55 Sat 2021-02-13 20:09:30 IST—Sat 2021-02-13 20:10:44 IST
-1 94b604a6bf75462dac8c4a4576fdc863 Sat 2021-02-13 20:10:59 IST—Sat 2021-02-13 20:23:18 IST
0 3ff7e29fa0a34878b7574b7d4d3ccfb5 Sat 2021-02-13 20:24:57 IST—Sat 2021-02-13 21:13:15 IST
$
Wie Sie sehen, werden mehrere Starts aufgelistet. Um einen bestimmten Neustart genauer zu analysieren, verwenden Sie:
$ journalctl -b {num} -n
Dabei ist {num} der Index aus der ersten Spalte des Befehls journalctl --list-boots.
$ journalctl -b -1 -n
-- Logs begin at Wed 2020-11-18 23:09:05 IST, end at Sat 2021-02-13 21:13:39 IST. --
Feb 13 20:23:18 ubuntumate20vm systemd[1]: lvm2-monitor.service: Succeeded.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Stopped Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Shutdown.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Final Step.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: systemd-poweroff.service: Succeeded.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Finished Power-Off.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Reached target Power-Off.
Feb 13 20:23:18 ubuntumate20vm systemd[1]: Shutting down.
Feb 13 20:23:18 ubuntumate20vm systemd-shutdown[1]: Syncing filesystems and block devices.
Feb 13 20:23:18 ubuntumate20vm systemd-journald[304]: Journal stopped
In der obigen Ausgabe können Sie die protokollierten Nachrichten im Journal beobachten und nach Anomalien suchen.
Fazit
Es ist nicht immer möglich, die Ursache eines Linux-Neustarts mit einem einzigen Befehl oder aus einer einzelnen Protokolldatei zu ermitteln. Daher ist es immer hilfreich, die Befehle und Protokolle zu kennen, die systembezogene Ereignisse aufzeichnen, um die Zeit zur Ursachenforschung zu verkürzen.
Die oben genannten Beispiele bieten einen Ausgangspunkt für die Fehlersuche. Durch die Kombination dieser Tools und Protokolle können Sie sicherstellen, dass Sie verstehen, was passiert ist und warum Ihr System neu gestartet wurde.
Informieren Sie sich als Nächstes über einige der leichtgewichtigen Überwachungssoftware für Linux.