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

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

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

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

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

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.

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

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

Редактировать : Кажется, типичная проблема, с которой люди могут столкнуться, заключается в том, что они работают 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.

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

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

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

$ systemctl show <service_name>

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

При конфигурации по умолчанию в 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 также перенаправляет все сообщения журнала в системный журнал, поэтому вы также должны найти эти сообщения в /var/log/syslog.

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

Может быть полезно знать, что по умолчанию systemd-journald хранит журналы в папке /run, которая tmpfsи, следовательно, исчезает после перезагрузки. Это означает, что для получения сообщений журнала старше, чем при последней загрузке, вам нужно будет просмотреть файлы системного журнала. В этом случае 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.

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

Мы можем использовать -fопцию для фильтрации сообщений из журнала ( https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html ).

journalctl -f _TRANSPORT=journal example