• Erledigen Sie die Anwendungssicherheit auf die richtige Weise! Erkennen, schützen, überwachen, beschleunigen und mehr…
  • Es kommt häufig vor, dass ein Linux-System ungeplant oder aus unbekannten offensichtlichen Gründen neu gestartet wurde. Das Finden und Beheben der Grundursache kann dazu beitragen, das Wiederauftreten solcher Probleme zu verhindern und ungeplante Ausfallzeiten zu vermeiden.

    Es gibt verschiedene Möglichkeiten, um herauszufinden, was einen Neustart ausgelöst hat. In diesem Artikel werden diese Möglichkeiten erläutert und wie Sie verfügbare Dienstprogramme und Protokolle in einem Linux-System verwenden können, um solche Szenarien zu beheben.

    Überprüfen Sie die Neustartzeit

    Sie können überprüfen, wann der Systemneustart mit stattgefunden hat who und last Befehle

    $ 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
    $

    Überprüfen Sie die Systemmeldungen

    Sie können den Neustart, den Sie diagnostizieren möchten, weiter mit Systemmeldungen korrelieren.

    Für CentOS / RHEL-Systeme finden Sie die Protokolle unter /var/log/messages während für Ubuntu / Debian-Systeme ist es angemeldet /var/log/syslog. Sie können einfach die verwenden tail Befehl oder Ihr bevorzugter Texteditor, um bestimmte Daten herauszufiltern oder zu finden.

    Wie aus den folgenden Protokollen hervorgeht, deuten solche Einträge auf ein Herunterfahren / Neustarten hin, das von einem Administrator oder Root-Benutzer initiiert wurde. Diese Meldungen können je nach Betriebssystemtyp und der Art und Weise, wie Neustart / Herunterfahren ausgelöst wird, variieren. Sie finden jedoch immer nützliche Informationen, wenn Sie sich die Systemprotokolle ansehen, obwohl diese möglicherweise nicht explizit genug sind, um die Ursache jedes Mal genau zu bestimmen.

    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.

    Ein solcher Befehl, mit dem Sie Systemprotokolle herausfiltern können, ist unten angegeben:

    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 möglicherweise nicht immer spezifisch. Verfolgen Sie immer Ereignisse, die Anzeichen von Warnungen oder Fehlern enthalten, die zum Ausschalten / Absturz des Systems führen können.

    Überprüfen Sie die auditd-Protokolle

    Für Systeme mit auditdEs ist ein großartiger Ort, um verschiedene Ereignisse mit zu überprüfen ausearch Werkzeug. Verwenden Sie den folgenden Befehl, um die letzten beiden Einträge aus Überwachungsprotokollen zu überprüfen.

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

    Dadurch werden die beiden letzten Abschaltungen oder Neustarts gemeldet. Wenn dies a meldet SYSTEM_SHUTDOWN gefolgt von einem SYSTEM_BOOTAlles sollte gut sein. Aber wenn es zwei meldet SYSTEM_BOOT Zeilen in einer Reihe oder nur eine einzelne SYSTEM_BOOT Leitung, dann wurde das System höchstwahrscheinlich nicht ordnungsgemäß heruntergefahren. Eine normale Ausgabe sollte ungefähr so ​​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 listet zwei aufeinanderfolgende auf SYSTEM_BOOT Nachrichten, die möglicherweise auf ein unansehnliches Herunterfahren hinweisen, obwohl sie mit Systemprotokollen korreliert werden müssen.

    $ 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'
    $

    Systemd Journal analysieren

    Sie sollten über ein dauerhaftes System-Journal verfügen, um ein dauerhaftes Journal auf der Festplatte zu führen. Andernfalls bleiben die Protokolle beim Neustart nicht bestehen. Dazu können Sie entweder die Änderungen in vornehmen /etc/systemd/journald.conf oder erstellen Sie das Verzeichnis selbst mit den folgenden Befehlen:

    $ sudo mkdir /var/log/journal
    $ sudo systemd-tmpfiles --create --prefix /var/log/journal 2>/dev/null
    $ sudo systemctl -s SIGUSR1 kill systemd-journald

    Anschließend können Sie das System optional neu starten, um mehr als einen Neustarteintrag im Journal zu erfassen, obwohl dies nicht erforderlich ist.

    Verwenden Sie den folgenden Befehl, um protokollierte Starts 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—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 können, dauert die Auflistung mehrere Stiefel. Verwenden Sie Folgendes, um einen bestimmten Neustart weiter zu analysieren:

    $ journalctl -b {num} -n

    {num} wird der Index in angegeben journalctl --list-boots Befehl in der ersten Spalte.

    $ 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
    $

    Sie können in der obigen Ausgabe im Journal protokollierte Nachrichten beobachten und gegebenenfalls die Anomalien aufspüren.

    Fazit

    Es ist möglicherweise nicht immer möglich, die Ursache eines Linux-Neustarts mit einem einzigen Befehl oder aus einer einzigen Protokolldatei zu ermitteln. Daher ist es immer praktisch, die Befehle und Protokolle zu kennen, mit denen systembezogene Ereignisse erfasst werden, und die Zeit zu verkürzen, die zum Auffinden der Grundursache erforderlich ist.

    Die obigen Beispiele bieten Ihnen einen Ausgangspunkt für die Fehlerbehebung. Mit einer Kombination solcher Tools und Protokolle können Sie sicher sein, dass Sie wissen, was passiert ist und wie Ihr System neu gestartet wurde.

    Als nächstes finden Sie einige der leichten Gewichte heraus Überwachungssoftware für Linux.