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

12

У меня есть служба (написанная мной), работающая на сервере 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.
systemd systemd-journald mindriot
источник
"не вижу таких сообщений журнала" - странно? У меня есть многоgrep systemd /var/log/syslog
hschou
В моей системе я вижу только очень общие сообщения, такие как Stopped target Defaultи Starting Shutdownт. Д. Ничего не указывает на отдельные услуги. Может быть, это просто проблема конфигурации? Заметьте, я в Debian Jessie в данном конкретном случае.
mindriot
Проверьте, что вы /etc/systemd/journald.confне переопределили MaxLevelStoreили MaxLevelSyslog, и посмотрите во всех других местах, где вы можете настроить journald, как указано в man journald.conf.
meuh
Спасибо за совет. К сожалению, все конфигурационные файлы, расположенные в unter /etc/systemd, по существу пусты (закомментированы все опции, включая те, что вы упомянули).
mindriot

Ответы:

11

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

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

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

$ systemctl show <service_name>

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

JDF
источник
Интересно, я не знал о свойствах. К сожалению, они устанавливаются одинаково, независимо от того, был ли сбой службы и повторно вызван, или служба была преднамеренно перезапущена пользователем.
mindriot
1
Между прочим, лучшей ссылкой для свойств является документация по dbus .
mindriot
Спасибо @mindriot, что это лучшая ссылка для документов, я обновил свой ответ.
jdf
1
@mindriot относительно вашей первой точки, вы проверили StatusErrnoи Result? Я хотел бы знать, если эти изменения, если служба не удалось или был перезапущен. Если вам действительно нужно пойти дальше, попробуйте добавить ExecStopPostшаг, где вы касаетесь файла и обновляете временную метку при завершении работы. Это поможет вам отличить тихий перезапуск от целенаправленных.
jdf
Спасибо, это тоже хороший момент. Я не смогу легко проверить / воспроизвести ситуацию; Моему оригинальному посту уже почти пол года, и с тех пор у нас было несколько изменений в системе. Я проверю, смогу ли я попробовать это где-нибудь, хотя - если у меня будет шанс.
mindriot
3

При конфигурации по умолчанию в 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.
Том Бьерк
источник
Спасибо за обширный и хорошо написанный пост, который, вероятно, решает проблему для большинства пользователей. К сожалению, в моем случае я не вижу каких - либо строк журнала приписываемые systemdпри выводе журнала , как вы описали, хотя я работал как корень все время. /var/log/syslogтоже ничего не показывает. Это systemd 215, кстати.
миндриот
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
klaypez
источник
1
serviceстарая команда Upstart, которая работает с systemd для совместимости Родная systemdкоманда есть systemctl status apache2.
Марк Стосберг
Спасибо. К сожалению, он показывает только, когда служба была (повторно) запущена, но не почему ; и он также показывает только текущую ситуацию, т. е. последний перезапуск.
mindriot