
У меня есть служба (написанная мной), запущенная на сервере 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