Come posso vedere quando un servizio systemd è stato avviato / arrestato / riavviato?

Ho un servizio (scritto da me stesso) in esecuzione su un server Debian (Jessie) e i registri del servizio indicano che è stato riavviato in un determinato momento. Non vi è alcuna indicazione di un segfault o di un altro arresto anomalo, quindi ora sto cercando di capire se l'applicazione in qualche modo non è riuscita in modo silenzioso e viene rigenerata da systemd o se un utente ha riavviato di proposito il servizio tramite systemctl.

La cronologia della shell non mostra tale attività, ma ciò non è conclusivo a causa export HISTCONTROL=ignorebothe perché una sessione SSH potrebbe essere scaduta, impedendo che la cronologia bash di un login precedente venga scritta su disco. Il server non è stato riavviato al momento.

Ma mi aspetto che systemd stesso dovrebbe tenere un registro che indica quando un servizio è stato riavviato di proposito . Con mia sorpresa non sono riuscito a trovare alcuna documentazione (ad esempio per journalctl) su come ottenere tali registri.

Alcuni altri post (ad es. Dove si trova / perché non esiste un registro per i normali servizi di sistema dell'utente? ) Sembrano indicare che dovrebbero esserci messaggi di registro come questo:

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.

Ma non vedo tali messaggi di registro sul mio sistema.

C'è un modo per scoprire quando sono stati avviati, arrestati o riavviati i servizi di systemd?

Modifica : sembra che il problema tipico che le persone potrebbero incontrare sia che si eseguono journalctlcome utenti non privilegiati. Questo non è il caso per me, ho operato per roottutto il tempo. In risposta a un commento, correre grep systemd /var/log/syslogmi dà solo questo:

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.

Se devi scrivere questo script, dovresti esaminare usando il systemctl show comando. È più utile per gli script che cercare di analizzare qualsiasi cosa status. Ad esempio, per trovare l'ultima volta che il servizio è stato avviato è possibile utilizzare:

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

Se desideri vedere tutte le proprietà disponibili, ometti la bandiera e le scaricherà tutte.

$ systemctl show <service_name>

La documentazione per queste proprietà è disponibile qui .

Con la configurazione predefinita su Debian, un utente senza privilegi non avrà accesso né ai registri di sistema né a quelli di sistema. Se hai effettuato l'accesso come utente normale, riceverai questa risposta da journalctl:

$ journalctl 
No journal files were found.

che è un po 'confuso.

Se hai effettuato l'accesso come root, journalctl --unit=yourservicedovresti fornirti le informazioni che stai cercando. Dopo un systemctl restart bind9sul mio server, ottengo questo dopo 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.

Se uccido esplicitamente bind9 kill -9, journalctl --unit=bind9dà:

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.

La prima riga indica che il processo è morto perché è stato ucciso.

systemd-journald inoltra anche tutti i messaggi di log a syslog, quindi dovresti trovare anche questi messaggi /var/log/syslog.

Systemd e systemd-journald hanno una configurazione predefinita compilata che può essere modificata in /etc/systemd/system.confe /etc/systemd/journald.conf.

Può essere utile sapere che, per impostazione predefinita, systemd-journald memorizza i log in /run, che è tmpfse quindi scompare dopo un riavvio. Ciò significa che per ottenere i messaggi di registro più vecchi dell'ultimo avvio, dovrai guardare i file syslog. In questo caso journalctl non ti darà registri più vecchi dell'ultimo avvio. Questo può essere modificato /etc/systemd/journald.confimpostando Storage=persistent.

Le pagine di manuale che documentano questo sono:

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

Inoltre, affinché un servizio possa essere riavviato automaticamente da systemd, questo deve essere configurato nel suo .servicefile. Da 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.

Puoi vedere l'ultima volta che il servizio è stato avviato o riavviato. Usa service chatty statuso systemctl status chatty. Ecco alcuni esempi di servizio apache2 o 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

la linea Active: active (running) since Wen. 2017-06-02 15:53:01 CEST; 21min agomostra come funziona il servizio ma non so se puoi visualizzare come un 'elenco' esattamente quello che stai cercando.

# 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

Possiamo usare l' -fopzione per filtrare i messaggi dal diario ( https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html ).

journalctl -f _TRANSPORT=journal example