Comment savoir à partir des journaux quelle est la cause de l'arrêt du système?

Par exemple, je vois ceci dans /var/log/messages:

Mar 01 23:12:34 hostname shutdown: shutting down for system halt

Y a-t-il un moyen de savoir ce qui a causé la fermeture? Par exemple, a-t-il été lancé depuis la console ou quelqu'un a-t-il appuyé sur le bouton d'alimentation, etc.

Seuls les programmes à privilèges root peuvent arrêter gracieusement un système. Ainsi, lorsqu'un système s'arrête normalement, il s'agit soit d'un utilisateur avec des privilèges root, soit d'un script acpi. Dans les deux cas, vous pouvez le savoir en consultant les journaux. Un arrêt acpi peut être provoqué par une pression sur le bouton d'alimentation, une surchauffe ou une batterie faible (ordinateur portable). J'ai oublié la troisième raison, le logiciel de l'onduleur en cas de panne d'alimentation, qui envoie quand même une alerte.

Récemment, j'ai eu un système qui a démarré à plusieurs reprises pour éteindre sans grâce, s'est avéré qu'il était en surchauffe et le mobo a été configuré pour simplement éteindre tôt. Le système n'a pas pu sauvegarder les journaux, mais heureusement, la surveillance de la température du système a montré qu'il commençait à augmenter juste avant la mise hors tension.

Donc, s’il s’agit d’un arrêt normal, il sera enregistré, s’il s’agit d’une intrusion ... bonne chance, et s’il s’agit d’un arrêt à froid, votre meilleure chance de le savoir est de contrôler et de surveiller son environnement.

Essayez les commandes suivantes:

Afficher la liste des dernières entrées de redémarrage: last reboot | less

Afficher la liste des dernières entrées d'arrêt: last -x | less

ou plus précisément: last -x | grep shutdown | less

Vous ne saurez pas qui l'a fait cependant. Si vous voulez savoir qui l'a fait, vous devrez ajouter un peu de code, ce qui signifie que vous saurez la prochaine fois.

J'ai trouvé cette ressource en ligne. Cela pourrait vous être utile:

Comment savoir qui ou quoi a stoppé mon système

Il y a plusieurs choses à vérifier:

Vérifier le résultat de la dernière commande -x

Exécutez cette commande * et comparez le résultat avec les exemples ci-dessous:

last -x | head | tac

Exemples d'arrêt normal

Un arrêt normal et une mise sous tension ressemblent à ceci (notez que vous avez un événement d'arrêt puis un événement d'amorçage du système):

runlevel (to lvl 0)   2.6.32- Sat Mar 17 08:48 - 08:51  (00:02) 
shutdown system down  ... <-- first the system shuts down   
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 3)       

Dans certains cas, vous pouvez voir ceci (notez qu'il n'y a pas de ligne concernant l'arrêt, mais le système était au niveau d'exécution 0, ce qui correspond à "l'état d'arrêt"):

runlevel (to lvl 0)   ... <-- first the system shuts down (init level 0)
reboot   system boot  ... <-- afterwards the system boots
runlevel (to lvl 2)   2.6.24-... Fri Aug 10 15:58 - 15:32 (2+23:34)   

Exemples d'arrêt inattendus

Un arrêt inattendu suite à une panne d’alimentation ressemble à ceci (notez que vous avez un événement d’amorçage du système sans événement antérieur d’arrêt du système):

runlevel (to lvl 3)   ... <-- the system was running since this momemnt
reboot   system boot  ... <-- then we've a boot WITHOUT a prior shutdown
runlevel (to lvl 3)   3.10.0-693.21.1. Sun Jun 17 15:40 - 09:51  (18:11)    

Examinez les journaux dans / var / log

Une commande bash pour filtrer les messages de journal les plus intéressants est la suivante:

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'

Lorsqu'une mise hors tension ou une défaillance matérielle inattendue se produit, les systèmes de fichiers ne seront pas correctement démontés. Par conséquent, lors du prochain démarrage, vous obtiendrez des journaux du type suivant:

EXT4-fs ... INFO: recovery required ... 
Starting XFS recovery filesystem ...
systemd-fsck: ... recovering journal
systemd-journald: File /var/log/journal/.../system.journal corrupted or uncleanly shut down, renaming and replacing.

Lorsque le système s'éteint parce que l'utilisateur a appuyé sur le bouton d'alimentation, vous obtenez des journaux comme celui-ci:

systemd-logind: Power key pressed.
systemd-logind: Powering Off...
systemd-logind: System is powering down.

Ce n'est que lorsque le système s'arrête de manière ordonnée que vous obtenez des journaux comme celui-ci:

rsyslogd: ... exiting on signal 15

Lorsque le système s'arrête en raison d'une surchauffe, vous obtenez des journaux comme celui-ci:

critical temperature reached...,shutting down

Si vous possédez un onduleur et exécutez un démon pour surveiller l’alimentation et l’arrêt, vous devez évidemment vérifier ses journaux (NUT enregistre sur / var / log / messages mais apcupsd enregistre sur / var / log / apcupsd *)

Remarques

*: Voici la description de lastsa page de manuel:

last [...] prints information about connect times of users. 
Records are printed from most recent to least recent.  
[...]
The special users reboot and shutdown log in when the system reboots
or (surprise) shuts down. 

Nous avions l'habitude headde conserver les 10 derniers événements et tacd'inverser l'ordre afin que nous ne soyons pas déroutés par le fait que les dernières impressions avaient été enregistrées du plus récent au moins récent.

Quelques fichiers de log possibles à explorer: (trouvé un système Ubuntu, mais j'espère qu'ils sont présents sur la plupart des systèmes Linux / Unix)

/var/log/debug
/var/log/syslog (will be pretty full and may be harder to browse)
/var/log/user.log
/var/log/kern.log
/var/log/boot

Encore une fois, ces fichiers journaux sont présents sur un système Ubuntu, les noms de fichiers peuvent donc être différents. La tailcommande est votre ami.

Simplifiez l’ lastaffichage des entrées d’arrêt du système, des modifications du niveau d’exécution et du filtrage sur shutdownet reboot:

last -x shutdown reboot

Pas entièrement satisfaisant

J'avais un besoin similaire sur un Debian 7.8 et observe que, fondamentalement, il n'y a pas de message clair et explicite dans le journal, ce qui est un peu surprenant.

Grep /var/logindiquerait l'heure à laquelle la machine a été arrêtée, montrait les démons appropriés, etc., mais pas la raison initiale.

shutdown[25861]: shutting down for system halt

Les autres solutions mentionnées ( last -x) n’ont pas beaucoup aidé.

En regardant comment ça marche

Lecture /etc/acpi/powerbtn-acpi-support.shqui comprend:

if [-x /etc/acpi/powerbtn.sh]; ensuite
    # Compatibilité avec l'ancien script de configuration du paquet acpid
    /etc/acpi/powerbtn.sh
elif [-x /etc/acpi/powerbtn.sh.dpkg-bak]; ensuite
        # Compatibilité avec l'ancien script de configuration du paquet acpid
    # qui existe toujours car il a été modifié par l'administrateur
        /etc/acpi/powerbtn.sh.dpkg-bak
autre
    # Manipulation normale.
    / sbin / shutdown -h -P maintenant "Bouton d'alimentation enfoncé"
Fi

Notez qu'un texte explicite est donné en tant que paramètre de la shutdowncommande. Je m'attendrais à ce que cette chaîne soit enregistrée automatiquement par le programme d'arrêt.

Ajuster pour de meilleurs journaux

Quoi qu’il en soit, pour obtenir un message explicite, je mets le texte ci-dessous (en tant que root) dans un /etc/acpi/powerbtn.shexécutable nouvellement créé avecchmod a+x /etc/acpi/powerbtn.sh

#! / bin / sh
logger dans /etc/acpi/powerbtn.sh, probablement "bouton d'alimentation enfoncé"
    / sbin / shutdown -h -P maintenant "Bouton d'alimentation enfoncé"

Le faire de cette façon entraînera probablement un changement plus durable que la modification /etc/acpi/powerbtn-acpi-support.sh. Cette dernière option perdrait probablement son effet sur la prochaine mise à jour du paquet acpi-support-base.

Notez que Ubuntu 14.04 le fait différemment ( /etc/acpi/powerbtn.shexiste déjà avec un contenu différent du acpidpaquet). En outre, Debian 8 le fait probablement différemment. N'hésitez pas à proposer des variantes.

Profit!

Et maintenant, lorsque vous appuyez sur le bouton d'alimentation, une ligne comme ci-dessous apparaît dans /var/log/messages, /var/log/sysloget /var/log/user.log:

logger: in /etc/acpi/powerbtn.sh, presumably Power button pressed

Voilà un message explicite dans le journal.

J'ai juste une idée maladroite, mais peut-être que cela fonctionne pour vous: entrez la commande lastet consultez les informations de connexion de tous les utilisateurs. ensuite, filtrez les utilisateurs avec l’autorisation requise pour haltcela qui avait été connecté à ce moment. puis consultez leur .bash_historydossier pour voir s’ils se sont arrêtés ou non.

Dans mon cas, j'ai eu un problème de surchauffe et j'ai trouvé le journal dans / var / log / syslog par un message 'grep shut *' dans le dossier / var / log.

L'erreur enregistrée était la suivante:

Feb 23 15:59:49 luca-LIFEBOOK-A530 kernel: [24746.497174] thermal thermal_zone0: critical temperature reached(99 C),shutting down

Il suffit de la noter sur ma machine virtuelle KVM (où je me demandais si un redémarrage d’hôte entraînait un arrêt complet des invités), j’ai trouvé ce dont j'avais besoin /var/log/auth.log(en plus de le last -x shutdownmontrer de la même manière). Là, ces lignes sont apparues:

Sep  3 23:56:31 Web systemd-logind[531]: Power key pressed.
Sep  3 23:56:31 Web systemd-logind[531]: Powering Off...
Sep  3 23:56:31 Web systemd-logind[531]: System is powering down.
Sep  3 23:55:45 Web systemd-logind[591]: New seat seat0.
Sep  3 23:55:45 Web systemd-logind[591]: Watching system buttons on /dev/input/event0 (Power Button)
Sep  3 23:55:54 Web sshd[805]: Server listening on 0.0.0.0 port 22.
Sep  3 23:55:54 Web sshd[805]: Server listening on :: port 22.

last -xaffiche ces lignes, remarquez qu'elles sont imprimées dans l'ordre le plus récent-premier (c.-à-d. lisez la dernière ligne en premier, puis montez), mais en raison de la réinitialisation de l'horloge (23h56 avant le démarrage, 23h55 après) également évident dans les lignes précédentes, l'ordre semble un peu déroutant:

runlevel (to lvl 2)   3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
reboot   system boot  3.13.0-129-gener Sun Sep  3 23:55 - 22:04  (22:08)    
shutdown system down  3.13.0-123-gener Sun Sep  3 23:56 - 23:55  (00:00)    
runlevel (to lvl 0)   3.13.0-123-gener Sun Sep  3 23:56 - 23:56  (00:00)

Pour ma part, vérifier que les invités sont correctement fermés lorsque l'hôte est démarré, je pourrais aussi simplement me connecter à l'un des invités (ssh) et y rester lorsque j'amorcerai l'hôte en obtenant ces lignes dans le terminal:

root@Web:~#
Broadcast message from root@Web
        (unknown) at 22:25 ...

The system is going down for power off NOW!
Connection to web closed by remote host.
Connection to web closed.

alias l'arrêt d'un script,
le script doit donner tous les paramètres, etc. à l'exécutable d'arrêt d'origine
MAIS: le script doit enregistrer ceux-ci

cat /usr/adm/syslog

dans mon cas, c’était le logiciel d’ups qui arrêtait le serveur.

/etc/rc.d/7/upsd.boot