Geekflare wird von unserem Publikum unterstützt. Es kann sein, dass wir durch den Kauf von Links auf dieser Seite Affiliate-Provisionen verdienen.
Unter Linux Zuletzt aktualisiert: September 24, 2023
Weitergeben:
Freshdesk - Die benutzerfreundliche Software für den Kundensupport, die Ihnen hilft, Ihre Kunden zufrieden zu stellen.

Es kommt häufig vor, dass wir feststellen, dass ein Linux-System ungeplant oder aus unbekannten offensichtlichen Gründen neu gebootet wurde. Die Suche nach der Ursache und deren Behebung kann helfen, das erneute Auftreten solcher Probleme zu verhindern und ungeplante Ausfallzeiten zu vermeiden

Es gibt mehrere Möglichkeiten herauszufinden, was einen Neustart ausgelöst hat. In diesem Artikel gehen wir auf diese Möglichkeiten ein und erläutern, wie Sie die in einem Linux-System verfügbaren Dienstprogramme und Protokolle nutzen können, um derartige Szenarien zu beheben

Inspektion der Neustartzeit

Mit den Befehlen who und last können Sie überprüfen, wann der Neustart des Systems erfolgt ist

$ 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 immer noch eingeloggt

$

Systemnachrichten prüfen

Sie können den Reboot, den Sie diagnostizieren möchten, weiter mit Systemmeldungen in Verbindung bringen

Bei CentOS/RHEL-Systemen finden Sie die Protokolle unter /var/log/messages, während sie bei Ubuntu/Debian-Systemen unter /var/log/syslog gespeichert werden. Sie können einfach den Befehl tail oder Ihren bevorzugten Texteditor verwenden, um bestimmte Daten herauszufiltern oder zu finden

Wie Sie den unten stehenden Protokollen entnehmen können, deuten diese Einträge auf einen von einem Administrator oder Root-Benutzer initiierten Shutdown/Reboot hin. Diese Meldungen können je nach Betriebssystemtyp und der Art und Weise, wie ein Neustart/Herunterfahren ausgelöst wird, variieren, aber Sie werden immer nützliche Informationen finden, wenn Sie sich die Systemprotokolle ansehen, auch wenn sie nicht immer eindeutig genug sind, um die Ursache zu ermitteln

Feb 13 19:56:20 centos7vm chronyd<x>[637]</x>: Quelle 72.30.35.89 durch 142.147.92.5 ersetzt
Feb 13 20:00:40 centos7vm chronyd<x>[637]</x>: Ausgewählte Quelle 162.159.200.123
Feb 13 20:01:01 centos7vm systemd: Slice User Slice von root erstellt.
Feb 13 20:01:01 centos7vm systemd: Sitzung 2 des Benutzers root gestartet.
Feb 13 20:04:09 centos7vm systemd-logind: Das System wird heruntergefahren.
Feb 13 20:04:09 centos7vm systemd: LVM2 poll daemon socket geschlossen.
Feb 13 20:04:09 centos7vm systemd: Ziel Multi-User System gestoppt

Ein solcher Befehl, den Sie verwenden können, um Systemprotokolle herauszufiltern, lautet wie folgt

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'

Erfasste Ereignisse sind nicht immer spezifisch. Suchen Sie immer nach Ereignissen, die auf Warnungen oder Fehler hindeuten, die zum Ausschalten/Absturz des Systems führen können

Überprüfen der auditd-Protokolle

Bei Systemen mit auditd können Sie verschiedene Ereignisse mit dem Tool ausearch überprüfen. Verwenden Sie den folgenden Befehl, um die letzten beiden Einträge in den Audit-Protokollen zu überprüfen

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4

Dies meldet die beiden letzten Shutdowns oder Reboots. Wenn dies einen SYSTEM_SHUTDOWN gefolgt von einem SYSTEM_BOOT meldet, sollte alles in Ordnung sein. Wenn jedoch zwei SYSTEM_BOOT-Zeilen hintereinander oder nur eine einzige SYSTEM_BOOT-Zeile gemeldet werden, wurde das System höchstwahrscheinlich nicht ordnungsgemäß heruntergefahren. Eine normale Ausgabe sollte in etwa wie folgt aussehen

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_SHUTDOWN msg=audit(Samstag 13 Februar 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(Samstag 13. Februar 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 listet zwei aufeinanderfolgende SYSTEM_BOOT-Meldungen auf, was auf ein nicht ordnungsgemäßes Herunterfahren hindeuten könnte, allerdings muss dies mit den Systemprotokollen abgeglichen werden

$ sudo ausearch -i -m system_boot,system_shutdown | tail -4
----
type=SYSTEM_BOOT msg=audit(Samstag 13 Februar 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(Samstag 13 Februar 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'

$

Systemd-Journal auswerten

Sie sollten ein persistentes systemd-journal haben, um ein persistentes Journal auf der Festplatte zu führen, sonst bleiben die Protokolle beim Neustart nicht erhalten. Dazu können Sie entweder die Änderungen in /etc/systemd/journald.conf vornehmen oder das Verzeichnis mit den folgenden Befehlen selbst erstellen

$ sudo mkdir /var/log/journal

$

 sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null

$

 sudo systemctl -s SIGUSR1 kill systemd-journald

Sobald dies geschehen ist, können Sie das System optional neu starten, um mehr als einen Neustart-Eintrag im Journal zu erfassen, obwohl dies nicht erforderlich ist

Verwenden Sie den folgenden Befehl, um die protokollierten Neustarts aus dem Journal aufzulisten

$ journalctl --list-boots

Hier ist die Ausgabe auf 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-Due 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, dauert die Auflistung mehrere Neustarts. Um einen bestimmten Neustart weiter zu analysieren, verwenden Sie

$ journalctl -b {num} -n

Dabei ist {num} der Index, der im Befehl journalctl --list-boots in der ersten Spalte angegeben ist

$ journalctl -b -1 -n
-- Die Protokolle beginnen am Wed 2020-11-18 23:09:05 IST und enden am Sat 2021-02-13 21:13:39 IST. --
Feb 13 20:23:18 ubuntumate20vm systemd<x><x><x><x><x><x><x><x>[1]</x></x></x></x></x></x></x></x>: lvm2-monitor.service: Erfolgreich.
Feb 13 20:23:18 ubuntumate20vm systemd<x><x><x><x><x><x><x><x>[1</x></x></x></x></x></x></x></x>]: Überwachung von LVM2-Spiegeln, Snapshots usw. mittels dmeventd oder Progress Polling gestoppt.
Feb 13 20:23:18 ubuntumate20vm systemd<x><x><x><x><x><x><x><x>[1]</x></x></x></x></x></x></x></x>: Das Ziel Shutdown wurde erreicht.
Feb 13 20:23:18 ubuntumate20vm systemd<x><x><x><x><x><x><x><x>[1]</x></x></x></x></x></x></x></x>: Ziel erreicht: Letzter Schritt.
Feb 13 20:23:18 ubuntumate20vm systemd<x><x><x><x><x><x><x><x>[1]</x></x></x></x></x></x></x></x>: systemd-poweroff.service: Succeeded.
Feb 13 20:23:18 ubuntumate20vm systemd<x><x><x><x><x><x><x><x>[1]</x></x></x></x></x></x></x></x>: Power-Off abgeschlossen.
Feb 13 20:23:18 ubuntumate20vm systemd<x><x><x><x><x><x><x><x>[1]</x></x></x></x></x></x></x></x>: Ziel Power-Off erreicht.
Feb 13 20:23:18 ubuntumate20vm systemd<x><x><x><x><x><x><x><x>[1]</x></x></x></x></x></x></x></x>: Herunterfahren.
Feb 13 20:23:18 ubuntumate20vm systemd-shutdown<x><x><x><x><x><x><x><x>[1]</x></x></x></x></x></x></x></x>: Dateisysteme und Blockgeräte synchronisieren.
Feb 13 20:23:18 ubuntumate20vm systemd-journald[304]: Journal gestoppt

$
Sie können die im Journal protokollierten Meldungen in der obigen Ausgabe beobachten und eventuelle Anomalien aufspüren

Schlussfolgerung

Es ist nicht immer möglich, die Ursache für einen Linux-Neustart mit einem einzigen Befehl oder anhand einer einzigen Protokolldatei zu ermitteln. Daher ist es immer praktisch, die Befehle und Protokolle zu kennen, die systembezogene Ereignisse aufzeichnen und die Zeit verkürzen können, die für die Suche nach der Ursache benötigt wird

Die oben genannten Beispiele bieten Ihnen einen Ausgangspunkt für Ihre Fehlersuche. Wenn Sie eine Kombination aus solchen Tools und Protokollen verwenden, können Sie sicher sein, dass Sie wissen, was passiert ist und wie Ihr System neu gebootet wurde

Als nächstes sollten Sie einige der leichtgewichtigen Überwachungsprogramme für Linux kennenlernen.

  • Abhishek Nair
    Autor
Dank an unsere Sponsoren
Weitere gute Lektüre zu Linux
Energie für Ihr Unternehmen
Einige der Tools und Dienste, die Ihr Unternehmen beim Wachstum unterstützen.
  • Das Text-to-Speech-Tool, das mithilfe von KI realistische, menschenähnliche Stimmen erzeugt.
    Versuchen Sie Murf AI
  • Web Scraping, Residential Proxy, Proxy Manager, Web Unlocker, Search Engine Crawler und alles, was Sie zum Sammeln von Webdaten benötigen.
    Versuchen Sie Brightdata
  • Monday.com ist ein All-in-One-Betriebssystem, mit dem Sie Projekte, Aufgaben, Arbeit, Vertrieb, CRM, Arbeitsabläufe und vieles mehr verwalten können.
    Versuch Montag
  • Intruder ist ein Online-Schwachstellen-Scanner, der Schwachstellen in Ihrer Infrastruktur aufspürt, um kostspielige Datenschutzverletzungen zu vermeiden.
    Versuchen Sie Intruder