Comment savoir à partir des journaux ce qui a causé l'arrêt du système?
Par exemple. Je vois ça dans /var/log/messages:
Mar 01 23:12:34 hostname shutdown: shutting down for system halt
Existe-t-il un moyen de découvrir la cause de l'arrêt? Par exemple. at-il été exécuté à partir de la console, ou quelqu'un a appuyé sur le bouton d'alimentation, etc.?
Seuls les programmes privilégiés root peuvent arrêter un système en douceur. Ainsi, lorsqu'un système s'arrête de manière normale, il s'agit soit d'un utilisateur disposant de privilèges root, soit d'un script acpi. Dans les deux cas, vous pouvez le découvrir 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 UPS en cas de panne de courant, qui enverra quand même une alerte.
Récemment, j'ai eu un système qui a commencé à s'éteindre de manière disgracieuse à plusieurs reprises, s'est avéré qu'il surchauffait et le mobo a été configuré pour s'éteindre juste tôt. Le système n'a pas pu enregistrer les journaux, mais heureusement, la surveillance de la température du système a montré qu'il commençait à augmenter juste avant de s'éteindre.
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 cependant pas qui l'a fait. Si vous voulez savoir qui l'a fait, vous devrez ajouter un peu de code, ce qui signifie que vous le saurez la prochaine fois.
J'ai trouvé cette ressource en ligne. Cela pourrait vous être utile:
Vous devez examiner 2 choses:
- La sortie de la commande last -x
- Les fichiers journaux dans /var/log/
Utilisez ces 2 commandes et continuez à lire pour plus d'informations.
last -x | head | tac
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'
1) Concernant la sortie de la dernière commande -x
Exécutez cette commande * et comparez la sortie aux exemples ci-dessous:
last -x | head | tac
Exemples d'arrêt normal
Un arrêt et une mise sous tension normaux ressemblent à ceci (notez que vous avez un événement d'arrêt puis un événement de démarrage 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 sur l'arrêt mais que le système était au niveau d'exécution 0 qui est "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 inattendu
Un arrêt inattendu à cause d'une coupure de courant ressemble à ceci (notez que vous avez un événement de démarrage du système sans événement d'arrêt du système antérieur):
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)
2) Concernant les logs 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 inattendue ou une défaillance matérielle se produit, les systèmes de fichiers ne seront pas correctement démontés, donc au prochain démarrage, vous pourrez obtenir des journaux comme celui-ci:
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 correctement 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 avez un onduleur et exécutez un démon pour surveiller l'alimentation et l'arrêt, vous devez évidemment vérifier ses journaux (NUT se connecte sur/var/log/messages mais apcupsd se connecte sur/var/log/apcupsd *)
Notes
*: Voici la description de last à partir de sa 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 utilisons head pour conserver les 10 derniers événements et nous utilisons tac pour inverser l'ordre afin que nous ne soyons pas déroutés par le fait que les dernières impressions de l'événement le plus récent au moins récent.
Quelques fichiers journaux possibles à explorer: (a 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, donc les noms de fichiers peuvent être différents. La commande tail est votre amie.
Simplifiez l'utilisation de last en affichant les entrées d'arrêt du système et exécutez les changements de niveau et le filtrage sur shutdown et reboot:
last -x shutdown reboot
Pas entièrement satisfaisant
J'avais un besoin similaire sur Debian 7.8 et je constate qu'en gros, il n'y a pas de message clair et explicite dans le journal, ce qui est un peu surprenant.
Grep à travers /var/log indiquerait l'heure d'arrêt de la machine, indiquerait l'arrêt correct des démons, etc., mais pas la raison initiale.
shutdown[25861]: shutting down for system halt
Les autres solutions mentionnées (last -x) n'a pas beaucoup aidé.
En regardant comment cela fonctionne
En train de lire /etc/acpi/powerbtn-acpi-support.sh qui inclut:
si [-x /etc/acpi/powerbtn.sh]; puis # Compatibilité avec l'ancien script de configuration du package acpid /etc/acpi/powerbtn.sh[.____.[Elif [-x /etc/acpi/powerbtn.sh.dpkg-bak] ; puis # Compatibilité avec l'ancien script de configuration du package acpid # qui est toujours là car il a été modifié par l'administrateur /etc/acpi/powerbtn.sh.dpkg-bak else # Manipulation normale. /sbin/shutdown -h -P maintenant "Bouton d'alimentation enfoncé" fi
Notez qu'un texte explicite est donné comme paramètre de la commande shutdown. Je m'attendrais à ce que cette chaîne soit enregistrée automatiquement par le programme d'arrêt.
Ajustement 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.sh rendu exécutable avec chmod a+x /etc/acpi/powerbtn.sh
#!/bin/sh enregistreur dans /etc/acpi/powerbtn.sh, vraisemblablement "Bouton d'alimentation enfoncé" /sbin/shutdown -h -P maintenant "Bouton d'alimentation pressé"
Le faire de cette façon entraînera probablement un changement plus durable que la modification de /etc/acpi/powerbtn-acpi-support.sh. Cette dernière option perdrait probablement son effet sur la prochaine mise à niveau du package acpi-support-base.
Notez qu'Ubuntu 14.04 le fait différemment (/etc/acpi/powerbtn.sh existe déjà avec un contenu différent du package acpid). De plus, Debian 8 le fait probablement différemment. N'hésitez pas à proposer des variantes.
Profit!
Et maintenant, lorsque le bouton d'alimentation est enfoncé, une ligne comme ci-dessous apparaît dans /var/log/messages, /var/log/syslog et /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 last et consultez les informations de connexion pour tous les utilisateurs. puis, filtrez les utilisateurs avec l'autorisation requise pour halt qui avait été connecté à ce moment. puis consultez leur .bash_history fichier pour voir s'ils sont entrés en arrêt 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 '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 l'intégrer sur mon KVM VM (où je me demandais si un redémarrage de l'hôte a fait un arrêt net des invités), j'ai trouvé ce dont j'avais besoin dans /var/log/auth.log (En plus de last -x shutdown Montrant la même chose). 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 -x Affiche ces lignes, notez qu'elles sont imprimées dans l'ordre le plus récent-le premier (c.-à-d. Lisez d'abord la dernière ligne, puis montez), mais à cause de l'horloge reset (23:56 avant le démarrage, 23:55 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, en vérifiant que les invités s'arrêtent proprement lorsque l'hôte est démarré, je pourrais également me connecter à (ssh) l'un des invités et y rester lorsque je démarre l'hôte, 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