Comment puis-je voir quand un service systemd a été démarré / arrêté / redémarré?

12

J'ai un service (écrit par moi-même) fonctionnant sur un serveur Debian (Jessie), et les propres journaux du service indiquent qu'il a redémarré à un moment particulier. Il n'y a aucune indication d'une erreur de segmentation ou d'un autre plantage, donc j'essaie maintenant de savoir si l'application a échoué silencieusement et a été réapparue par systemd, ou si un utilisateur a volontairement redémarré le service via systemctl.

L'historique du shell ne montre pas une telle activité, mais cela n'est pas concluant à cause export HISTCONTROL=ignorebothet parce qu'une session SSH peut avoir juste expiré, empêchant l'historique bash d'une connexion précédente d'être écrit sur le disque. Le serveur n'a pas été redémarré à l'époque.

Mais je m'attendrais à ce que systemd lui-même conserve un journal indiquant quand un service a été volontairement redémarré. À ma grande surprise, je n'ai pas pu trouver de documentation (par exemple pour journalctl) sur la façon d'obtenir de tels journaux.

Certains autres messages (par exemple, où est / pourquoi n'y a-t-il pas de journal pour les services systemd de l'utilisateur normal? ) Semblent indiquer qu'il devrait y avoir des messages de journal comme celui-ci:

Jan 15 19:28:08 qbd-x230-suse.site systemd[1]: Starting chatty.service...
Jan 15 19:28:08 qbd-x230-suse.site systemd[1]: Started chatty.service.

Mais je ne vois pas de tels messages de journal sur mon système.

Existe-t-il un moyen de savoir quand les services systemd ont été démarrés, arrêtés ou redémarrés?

Edit : Il semble que le problème typique que les gens peuvent rencontrer est qu'ils s'exécutent en journalctltant qu'utilisateur non privilégié. Ce n'est pas le cas pour moi, j'opère depuis roottoujours. En réponse à un commentaire, courir grep systemd /var/log/syslogne me donne que ceci:

Jun  6 09:28:35 server systemd[22057]: Starting Paths.
Jun  6 09:28:35 server systemd[22057]: Reached target Paths.
Jun  6 09:28:35 server systemd[22057]: Starting Timers.
Jun  6 09:28:35 server systemd[22057]: Reached target Timers.
Jun  6 09:28:35 server systemd[22057]: Starting Sockets.
Jun  6 09:28:35 server systemd[22057]: Reached target Sockets.
Jun  6 09:28:35 server systemd[22057]: Starting Basic System.
Jun  6 09:28:35 server systemd[22057]: Reached target Basic System.
Jun  6 09:28:35 server systemd[22057]: Starting Default.
Jun  6 09:28:35 server systemd[22057]: Reached target Default.
Jun  6 09:28:35 server systemd[22057]: Startup finished in 59ms.
Jun  6 09:37:08 server systemd[1]: Reexecuting.
systemd  systemd-journald 
— mindriot
source
"ne voyez pas ces messages de journal" - étrange? J'ai beaucoup de choses à fairegrep systemd /var/log/syslog
— hschou
Sur mon système, je ne vois que des messages très génériques tels que Stopped target Default, Starting Shutdownetc. Rien n'indiquant rien sur les services individuels. C'est peut-être juste un problème de configuration? Remarque Je suis sur Debian Jessie dans ce cas particulier.
— mindriot
Vérifiez que vous n'avez /etc/systemd/journald.confpas remplacé MaxLevelStoreou MaxLevelSysloget recherchez dans tous les autres endroits où vous pouvez configurer journald comme indiqué dans man journald.conf.
— meuh
Merci pour le conseil. Malheureusement, tous les fichiers de configuration situés sous un /etc/systemdsont essentiellement vides (toutes les options ont été commentées, y compris celles que vous avez mentionnées).
— mindriot

Réponses:

11

Si vous avez besoin de créer un script, vous devriez envisager d'utiliser la systemctl show commande. Il est plus utile pour les scripts que d'essayer d'analyser quoi que ce soit status. Par exemple, pour savoir quand le service a démarré pour la dernière fois, vous pouvez utiliser:

$ systemctl show systemd-journald --property=ActiveEnterTimestamp
ActiveEnterTimestamp=Wed 2017-11-08 05:55:17 UTC

Si vous souhaitez voir toutes les propriétés disponibles, omettez simplement l'indicateur et il les supprimera toutes.

$ systemctl show <service_name>

La documentation de ces propriétés se trouve ici .

— jdf
source
Intéressant, je ne connaissais pas les propriétés. Malheureusement, ils sont définis de la même manière, que le service ait échoué et soit réapparu, ou que le service ait été volontairement redémarré par un utilisateur.
— mindriot
1
Soit dit en passant, un meilleur lien pour les propriétés semble être la documentation dbus .
— mindriot
Merci @mindriot qui est un meilleur lien pour les documents, j'ai mis à jour ma réponse.
— jdf
1
@mindriot concernant votre premier point, avez-vous vérifié StatusErrnoet Result? Je me demande si ceux-ci changent si le service a échoué ou a été redémarré. Si vous devez vraiment aller plus loin, essayez d'ajouter une ExecStopPostétape où vous touchez un fichier et mettez à jour un horodatage à l'arrêt. Cela vous aidera à faire la différence entre les redémarrages silencieux et les redémarrages ciblés.
— jdf
Merci, c'est aussi un bon point. Je ne pourrai pas vérifier / reproduire la situation facilement; mon message d'origine a déjà presque un an et demi et nous avons depuis apporté quelques modifications au système. Je vais vérifier si je peux l'essayer quelque part - si j'en ai l'occasion.
— mindriot
3

Avec la configuration par défaut sur Debian, un utilisateur non privilégié n'aura accès ni aux journaux systemd-journald, ni à Syslog. Si vous êtes connecté en tant qu'utilisateur normal, vous recevrez cette réponse de journalctl:

$ journalctl 
No journal files were found.

ce qui est un peu déroutant.

Si vous êtes connecté en tant que root, journalctl --unit=yourservicedevrait vous donner les informations que vous recherchez. Après un systemctl restart bind9sur mon serveur, j'obtiens ceci après journalctl --unit=bind9:

Jun 03 18:20:24 ns systemd[1]: Stopping BIND Domain Name Server...
Jun 03 18:20:24 ns named[27605]: received control channel command 'stop'
Jun 03 18:20:24 ns systemd[1]: Starting BIND Domain Name Server...
Jun 03 18:20:24 ns systemd[1]: Started BIND Domain Name Server.

Si je tue explicitement bind9 avec kill -9, journalctl --unit=bind9donne:

Jun 03 18:46:25 ns systemd[1]: bind9.service: main process exited, code=killed, status=9/KILL
Jun 03 18:46:25 ns rndc[28028]: rndc: connect failed: 127.0.0.1#953: connection refused
Jun 03 18:46:25 ns systemd[1]: bind9.service: control process exited, code=exited status=1
Jun 03 18:46:25 ns systemd[1]: Unit bind9.service entered failed state.
Jun 03 18:46:25 ns systemd[1]: bind9.service holdoff time over, scheduling restart.
Jun 03 18:46:25 ns systemd[1]: Stopping BIND Domain Name Server...
Jun 03 18:46:25 ns systemd[1]: Starting BIND Domain Name Server...
Jun 03 18:46:25 ns systemd[1]: Started BIND Domain Name Server.

La première ligne indique que le processus est mort parce qu'il a été tué.

systemd-journald transmet également tous les messages de journal à syslog, vous devriez donc également trouver ces messages dans /var/log/syslog.

Systemd et systemd-journald ont une configuration compilée par défaut qui peut être modifiée dans /etc/systemd/system.confet /etc/systemd/journald.conf.

Il peut être utile de savoir que par défaut, systemd-journald stocke les journaux sous /run, ce qui est tmpfs, et disparaît donc après un redémarrage. Cela signifie que pour obtenir des messages de journal plus anciens que le dernier démarrage, vous devrez regarder les fichiers syslog. Dans ce cas, journalctl ne vous donnera pas de journaux plus anciens que le dernier démarrage. Cela peut être modifié en /etc/systemd/journald.confdéfinissant Storage=persistent.

Les pages de manuel qui documentent ceci sont:

man 8 systemd-journald
man 5 journald.conf
man 5 systemd-system.conf
man 5 systemd-user.conf

Notez également que pour qu'un service soit redémarré automatiquement par systemd, cela doit être configuré dans son .servicefichier. De man 5 systemd.service:

   Restart=
       Configures whether the service shall be
       restarted when the service process exits, is
       killed, or a timeout is reached. The service
       process may be the main service process, but it
       may also be one of the processes specified with
       ExecStartPre=, ExecStartPost=, ExecStop=,
       ExecStopPost=, or ExecReload=. When the death
       of the process is a result of systemd operation
       (e.g. service stop or restart), the service
       will not be restarted. Timeouts include missing
       the watchdog "keep-alive ping" deadline and a
       service start, reload, and stop operation
       timeouts.

       Takes one of no, on-success, on-failure,
       on-abnormal, on-watchdog, on-abort, or always.
       If set to no (the default), the service will
       not be restarted.
— Tom Bjerck
source
Merci pour le message complet et bien écrit qui résout probablement le problème pour la plupart des utilisateurs. Malheureusement, dans mon cas, je ne vois aucune ligne de journal attribuée à la systemdsortie du journal comme vous l'avez décrit, même si j'ai toujours travaillé en tant que root. /var/log/syslogne montre rien non plus. C'est d'ailleurs Systemd 215.
— mindriot
3

Vous pouvez voir la dernière fois que votre service a démarré ou redémarré. Utilisez service chatty statusou systemctl status chatty. Voici des exemples pour le service apache2 ou httpd:

# service apache2 status
● apache2.service - LSB: Apache2 web server
   Loaded: loaded (/etc/init.d/apache2)
  Drop-In: /lib/systemd/system/apache2.service.d
       └─forking.conf
   Active: active (running) since ven. 2017-06-02 15:53:01 CEST; 21min ago
  Process: 14773 ExecStop=/etc/init.d/apache2 stop (code=exited, status=0/SUCCESS)
  Process: 22912 ExecReload=/etc/init.d/apache2 reload (code=exited, status=0/SUCCESS)
  Process: 14880 ExecStart=/etc/init.d/apache2 start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/apache2.service

la ligne Active: active (running) since Wen. 2017-06-02 15:53:01 CEST; 21min agomontre depuis comment le service fonctionne mais je ne sais pas si vous pouvez afficher comme une «liste» exactement ce que vous recherchez.

# systemctl status httpd

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-10-11 00:35:58 EEST; 1 weeks 3 days ago
     Docs: man:httpd(8)
           man:apachectl(8)
  Process: 29728 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
 Main PID: 10722 (httpd)
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
   Memory: 8.7M
— klaypez
source
1
serviceest une ancienne commande Upstart qui fonctionne avec systemd pour la compatibilité. La systemdcommande native est systemctl status apache2.
— Mark Stosberg
Merci. Malheureusement, cela ne montre que quand le service a été (re) démarré, mais pas pourquoi ; et il montre également uniquement la situation actuelle , c'est-à-dire le dernier redémarrage.
— mindriot
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.