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

12

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.
Mindriot
źródło
„nie widzę takich komunikatów w dzienniku” - dziwne? Mam dużo ingrep systemd /var/log/syslog
hschou
W moim systemie widzę tylko wiadomości bardzo ogólne, takie jak Stopped target Default, Starting Shutdownitd. Nic nie wskazuje nic na temat poszczególnych usług. Może to tylko problem z konfiguracją? Uwaga: W tym konkretnym przypadku jestem na Debianie Jessie.
mindriot
Sprawdź, czy /etc/systemd/journald.confnie zostało zastąpione MaxLevelStorelub MaxLevelSyslogi sprawdź wszystkie inne miejsca, w których możesz skonfigurować dziennik zgodnie z listą man journald.conf.
Meuh
Dzięki za wskazówkę. Niestety, wszystkie pliki konfiguracyjne znajdujące się poniżej /etc/systemdsą zasadniczo puste (wszystkie opcje skomentowane, w tym te, o których wspomniałeś).
mindriot

Odpowiedzi:

11

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 .

jdf
źródło
Co ciekawe, nie wiedziałem o właściwościach. Niestety są one ustawione tak samo, niezależnie od tego, czy usługa uległa awarii i odrodziła się, czy też celowo usługa została ponownie uruchomiona przez użytkownika.
mindriot
1
Nawiasem mówiąc, lepszym łączem do właściwości wydaje się być dokumentacja dbus .
mindriot
Dzięki @mindriot, który jest lepszym linkiem do dokumentów, zaktualizowałem swoją odpowiedź.
jdf
1
@mindriot, jeśli chodzi o twój pierwszy punkt, sprawdziłeś StatusErrnoi Result? Zastanawiałbym się, czy zmieniają się one, jeśli usługa ulegnie awarii lub zostanie ponownie uruchomiona. Jeśli naprawdę potrzebujesz przejść dalej, spróbuj dodać ExecStopPostkrok, w którym dotkniesz pliku i zaktualizuj znacznik czasu podczas zamykania. Pomoże Ci to rozróżnić ciche restarty od celowych.
jdf
Dzięki, to także dobra uwaga. Nie będę w stanie łatwo sprawdzić / odtworzyć sytuacji; mój oryginalny post ma już prawie pół roku i od tego czasu wprowadziliśmy kilka zmian w systemie. Sprawdzę jednak, czy mogę gdzieś to wypróbować - jeśli będę miał szansę.
mindriot,
3

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.
Tom Bjerck
źródło
Dziękujemy za obszerny i dobrze napisany post, który prawdopodobnie rozwiązuje problem większości użytkowników. Niestety, w moim przypadku nie widzę żadnych wierszy dziennika przypisywanych systemdpodczas generowania dziennika zgodnie z opisem, mimo że cały czas pracowałem jako root. /var/log/syslogteż niczego nie pokazuje. Nawiasem mówiąc, jest to uporządkowane 215.
mindriot
3

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
klaypez
źródło
1
servicejest starą komendą Upstart, która działa z systememd dla kompatybilności. Natywnym systemdpoleceniem jest systemctl status apache2.
Mark Stosberg,
Dzięki. Niestety pokazuje tylko, kiedy usługa została (ponownie) uruchomiona, ale nie dlaczego ; i pokazuje także tylko bieżącą sytuację, tj. ostatni restart.
mindriot