Jak sprawdzić, kiedy usługa systemowa została uruchomiona / zatrzymana / zrestartowana?

Mam usługę (napisaną przeze mnie) działającą na serwerze Debian (Jessie), a własne dzienniki usługi wskazują, że została ona uruchomiona ponownie w określonym czasie. Nic nie wskazuje na awarię lub inną awarię, więc teraz próbuję dowiedzieć się, czy aplikacja jakoś cicho zawiodła i została odrodzona przez systemd, czy też użytkownik celowo zrestartował usługę za pośrednictwem systemctl.

Historia powłoki nie pokazuje takiej aktywności, ale nie jest to rozstrzygające z powodu export HISTCONTROL=ignorebothi ponieważ sesja SSH mogła właśnie przekroczyć limit czasu, uniemożliwiając zapisanie historii bashu poprzedniego logowania na dysku. Serwer nie został wówczas ponownie uruchomiony.

Spodziewałbym się jednak, że sam systemd powinien prowadzić dziennik wskazujący, kiedy usługa została celowo zrestartowana. Ku mojemu zdziwieniu nie udało mi się znaleźć żadnej dokumentacji (np. Dotyczącej journalctl), w jaki sposób uzyskać takie dzienniki.

Niektóre inne posty (np. Gdzie jest / dlaczego nie ma dziennika dla zwykłych usług systemowych użytkownika? ) Wydają się wskazywać, że powinny być takie komunikaty dziennika:

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.

Ale nie widzę takich komunikatów w dzienniku w moim systemie.

Czy istnieje sposób, aby dowiedzieć się, kiedy usługi systemowe zostały uruchomione, zatrzymane lub ponownie uruchomione?

Edycja : Wydaje się, że typowym problemem, na który mogą natknąć się ludzie, jest to, że działają journalctljako użytkownicy nieuprzywilejowani. To nie dotyczy mnie, działam rootprzez cały czas. W odpowiedzi na komentarz uruchomienie grep systemd /var/log/syslogdaje mi tylko to:

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.

Jeśli musisz to napisać, powinieneś skorzystać z systemctl show polecenia. Jest to bardziej przydatne dla skryptów niż próbowanie parsowania czegokolwiek status. Na przykład, aby dowiedzieć się, kiedy usługa została ostatnio uruchomiona, możesz użyć:

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

Jeśli chcesz zobaczyć wszystkie dostępne właściwości, po prostu pomiń flagę, a wszystkie zostaną zrzucone.

$ systemctl show <service_name>

Dokumentację tych właściwości można znaleźć tutaj .

Przy domyślnej konfiguracji Debiana nieuprzywilejowany użytkownik nie będzie miał dostępu ani do dzienników systemd ani dzienników syslog. Jeśli jesteś zalogowany jako zwykły użytkownik, otrzymasz odpowiedź z czasopisma:

$ journalctl 
No journal files were found.

co jest nieco mylące.

Jeśli jesteś zalogowany jako root, journalctl --unit=yourservicepowinien podać ci informacje, których szukasz. Po a systemctl restart bind9na moim serwerze otrzymuję to po 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.

Jeśli zabiję jawnie za pomocą bind9 kill -9, journalctl --unit=bind9daje:

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.

Pierwszy wiersz wskazuje, że proces zmarł, ponieważ został zabity.

systemd-journald przesyła również wszystkie wiadomości dziennika do syslog, więc powinieneś je również znaleźć w /var/log/syslog.

Systemd i systemd-journald mają domyślnie skompilowane w konfiguracji, które można zmienić w /etc/systemd/system.confi /etc/systemd/journald.conf.

Warto wiedzieć, że domyślnie systemd-Journald przechowuje logi pod /run, co oznacza tmpfs, i dlatego znika po ponownym uruchomieniu. Oznacza to, że aby komunikaty dziennika były starsze niż ostatni rozruch, musisz spojrzeć na pliki syslog. W tym przypadku dziennik nie dostarczy dzienników starszych niż ostatni rozruch. Można to zmienić /etc/systemd/journald.confpoprzez ustawienie Storage=persistent.

Strony podręcznika, które to dokumentują, to:

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

Należy również pamiętać, że aby usługa była restartowana automatycznie przez systemd, należy ją skonfigurować w .servicepliku. Od 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.

Możesz zobaczyć czas ostatniego uruchomienia lub ponownego uruchomienia usługi. Użyj service chatty statuslub systemctl status chatty. Oto przykłady usługi apache2 lub 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

linia Active: active (running) since Wen. 2017-06-02 15:53:01 CEST; 21min agopokazuje, jak działa usługa, ale nie wiem, czy możesz wyświetlać jak „listę” dokładnie to, czego szukasz.

# 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

Możemy użyć -fopcji filtrowania wiadomości z dziennika ( https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html ).

journalctl -f _TRANSPORT=journal example