• Assurez la sécurité des applications de la bonne manière! Détectez, protégez, surveillez, accélérez et plus encore…
  • Il arrive souvent que nous trouvions qu'un système Linux a redémarré de manière imprévue ou pour des raisons apparentes inconnues. La recherche et la résolution de la cause première peuvent aider à prévenir la récurrence de ces problèmes et à éviter les temps d'arrêt imprévus.

    Il y a plusieurs façons de savoir ce que déclenché un redémarrage. Dans cet article, nous allons discuter de ces méthodes et de la façon dont vous pouvez utiliser les utilitaires et les journaux disponibles dans un système Linux pour résoudre de tels scénarios.

    Inspecter l'heure de redémarrage

    Vous pouvez vérifier quand le redémarrage du système a eu lieu avec who et last commandes

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

    Vérifier les messages système

    Vous pouvez en outre mettre en corrélation le redémarrage que vous souhaitez diagnostiquer avec les messages système.

    Pour les systèmes CentOS / RHEL, vous trouverez les journaux sur /var/log/messages tandis que pour les systèmes Ubuntu / Debian, il est connecté à /var/log/syslog. Vous pouvez simplement utiliser le tail ou votre éditeur de texte préféré pour filtrer ou rechercher des données spécifiques.

    Comme on peut le déduire des journaux ci-dessous, ces entrées suggèrent un arrêt / redémarrage initié par un administrateur ou un utilisateur root. Ces messages peuvent varier en fonction du type de système d'exploitation et de la façon dont le redémarrage / l'arrêt est déclenché, mais vous trouverez toujours des informations utiles en consultant les journaux système, même si elles ne sont pas suffisamment explicites pour identifier la cause à chaque fois.

    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.

    Une telle commande que vous pouvez utiliser pour filtrer les journaux système est donnée ci-dessous:

    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'

    Les événements capturés peuvent ne pas toujours être spécifiques. Tracez toujours les événements qui donnent des signes d'avertissements ou d'erreurs susceptibles d'entraîner la mise hors tension / la panne du système.

    Vérifier les journaux d'audit

    Pour les systèmes avec auditd, c'est un endroit idéal pour consulter différents événements en utilisant ausearch outil. Utilisez la commande ci-dessous pour vérifier les deux dernières entrées des journaux d'audit.

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

    Cela signalera les deux derniers arrêts ou redémarrages. Si cela signale un SYSTEM_SHUTDOWN suivie d'une SYSTEM_BOOT, tout devrait être bon. Mais, s'il en rapporte deux SYSTEM_BOOT lignes d'affilée ou une seule SYSTEM_BOOT ligne, alors très probablement, le système ne s'est pas arrêté correctement. Une sortie normale devrait être quelque chose comme ci-dessous:

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

    La sortie ci-dessous répertorie deux SYSTEM_BOOT messages, qui peuvent indiquer un arrêt sans grâce bien qu'il doive être corrélé avec les journaux système.

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

    Analyser le journal systemd

    Vous devriez avoir un journal systemd persistant afin de conserver un journal persistant sur le disque, sinon les journaux ne persisteront pas au redémarrage. Pour cela, vous pouvez soit effectuer les modifications dans /etc/systemd/journald.conf ou créez le répertoire vous-même avec les commandes ci-dessous:

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

    Une fois terminé, vous pouvez éventuellement redémarrer le système pour capturer plus d'une entrée de redémarrage dans le journal bien que cela ne soit pas nécessaire.

    Utilisez la commande ci-dessous pour répertorier les démarrages enregistrés à partir du journal:

    $ journalctl --list-boots

    Voici sa sortie sur mon serveur:

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

    Comme vous pouvez le voir, la liste dure plusieurs bottes. Pour analyser plus en détail un redémarrage particulier, utilisez:

    $ journalctl -b {num} -n

    Ici {num} sera l'indice donné dans journalctl --list-boots commande dans la première colonne.

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

    Vous pouvez observer les messages enregistrés dans le journal dans la sortie ci-dessus et retracer les anomalies le cas échéant.

    Conclusion

    Il n'est pas toujours possible d'identifier la cause d'un redémarrage Linux à l'aide d'une seule commande ou à partir d'un seul fichier journal. En tant que tel, il est toujours pratique de connaître les commandes et les journaux qui capturent les événements liés au système et peuvent raccourcir le temps nécessaire pour trouver la cause première.

    Les exemples ci-dessus vous fournissent un point de départ pour commencer votre dépannage. En utilisant une combinaison de ces outils et journaux, vous pouvez être sûr de savoir ce qui s'est passé et comment votre système a redémarré.

    Ensuite, découvrez quelques-uns des poids légers logiciel de surveillance pour Linux.