Как узнать, когда была запущена/остановлена/перезапущена служба systemd?

Как узнать, когда была запущена/остановлена/перезапущена служба systemd?

У меня есть служба (написанная мной), запущенная на сервере Debian (Jessie), и собственные журналы службы указывают, что она перезапускалась в определенное время. Нет никаких указаний на segfault или другой сбой, поэтому я сейчас пытаюсь выяснить, может ли приложение каким-то образоммолчапроизошел сбой и был повторно запущен systemd, или пользователь намеренно перезапустил службу через systemctl.

История оболочки не показывает такой активности, но это не является окончательным из-за export HISTCONTROL=ignorebothи потому что сеанс SSH мог просто выйти из-за тайм-аута, не позволяя записать на диск историю bash предыдущего входа. Сервер не был перезагружен в то время.

Но я ожидаю, что сама systemd должна вести журнал, указывающий, когда служба быланамеренноперезапущен. К моему удивлению, я не смог найти никакой документации (например, для journalctl) о том, как получить такие логи.

Некоторые другие посты (напримерГде находится/почему нет журнала для обычных пользовательских служб systemd?) похоже, указывают на то, что должны быть такие сообщения в журнале:

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.

Но я не вижу таких сообщений в журнале моей системы.

Есть ли способ узнать, когда службы systemd были запущены, остановлены или перезапущены?

Редактировать: Похоже, типичная проблема, с которой могут столкнуться люди, заключается в том, что они работают journalctlкак непривилегированный пользователь. Это не мой случай, я rootвсе время работаю как пользователь. В ответ на комментарий, запуск grep systemd /var/log/syslogдает мне только это:

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.

решение1

Если вам нужно написать скрипт, вам следует рассмотреть возможность использования systemctl show команды. Это более полезно для скриптов, чем пытаться разобрать что-либо из status. Например, чтобы узнать, когда последний раз запускалась служба, можно использовать:

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

Если вы хотите увидеть все доступные свойства, просто уберите этот флажок, и они будут выведены на экран.

$ systemctl show <service_name>

Документацию по этим свойствам можно найтиздесь.

решение2

При конфигурации по умолчанию в Debian непривилегированный пользователь не будет иметь доступа ни к systemd-journald, ни к журналам syslog. Если вы вошли в систему как обычный пользователь, вы получите такой ответ от journalctl:

$ journalctl 
No journal files were found.

что немного сбивает с толку.

Если вы вошли в систему как root, journalctl --unit=yourserviceдолжно дать вам информацию, которую вы ищете. После systemctl restart bind9на моем сервере я получаю это после 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.

Если я явно убью bind9 с помощью kill -9, journalctl --unit=bind9то получим:

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.

Первая строка указывает на то, что процесс завершился, поскольку он был завершен.

systemd-journald также пересылает все сообщения журнала в syslog, поэтому вы также должны найти эти сообщения в /var/log/syslog.

Systemd и systemd-journald имеют скомпилированную по умолчанию конфигурацию, которую можно изменить в /etc/systemd/system.confи /etc/systemd/journald.conf.

Может быть полезно знать, что по умолчанию systemd-journald хранит журналы в /run, то есть tmpfs, и поэтому исчезает после перезагрузки. Это означает, что для того, чтобы получить сообщения журнала старше последней загрузки, вам придется просмотреть файлы syslog. В этом случае journalctl не выдаст вам журналы старше последней загрузки. Это можно изменить, /etc/systemd/journald.confустановив Storage=persistent.

Страницы руководства, в которых это документируется:

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

Также обратите внимание, что для того, чтобы служба автоматически перезапускалась systemd, это необходимо настроить в ее .serviceфайле. Из 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.

решение3

Вы можете увидеть последний раз, когда ваша служба запускалась или перезапускалась. Используйте service chatty statusили systemctl status chatty. Вот примеры для службы apache2 или 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

строка Active: active (running) since Wen. 2017-06-02 15:53:01 CEST; 21min agoпоказывает, как работает служба, но я не знаю, можно ли отобразить в виде «списка» именно то, что вы ищете.

# 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

Связанный контент