Як я бачу, коли системна послуга була запущена / зупинена / перезапущена?

У мене служба (написана власноруч) працює на сервері Debian (Jessie), і власні журнали служби вказують на те, що вона перезапустилася в певний час. Немає вказівки на сегментарний або інший збій, тому я зараз намагаюся з’ясувати, чи програма якось мовчки вийшла з ладу та перезапущена системою, чи користувач навмисно перезапустив службу через systemctl.

Історія оболонки не демонструє такої активності, але це не є переконливим через те, export HISTCONTROL=ignorebothі тому, що сеанс SSH, можливо, щойно закінчився, запобігаючи запису на диск попередньої історії входу. Сервер тоді не перезавантажувався.

Але я би сподівався, що сам 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, ні до журналів 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

Також зауважте, що для того, щоб сервіс автоматично запускався системою, це потрібно налаштувати у його .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