☰

Como posso ver quando um serviço systemd foi iniciado/interrompido/reiniciado?

tag-icon • tag-icon systemd systemd-journald
Como posso ver quando um serviço systemd foi iniciado/interrompido/reiniciado?

Eu tenho um serviço (escrito por mim) em execução em um servidor Debian (Jessie), e os próprios logs do serviço indicam que ele foi reiniciado em um determinado momento. Não há indicação de falha de segurança ou outra falha, então agora estou tentando descobrir se o aplicativo de alguma formasilenciosamentefalhou e foi respawnado pelo systemd, ou se um usuário reiniciou propositalmente o serviço via systemctl.

O histórico do shell não mostra tal atividade, mas isso não é conclusivo porque export HISTCONTROL=ignorebothuma sessão SSH pode ter expirado, impedindo que o histórico bash de um login anterior seja gravado no disco. O servidor não foi reinicializado no momento.

Mas eu esperaria que o próprio systemd mantivesse um log indicando quando um serviço foipropositalmentereiniciado. Para minha surpresa, não consegui encontrar nenhuma documentação (por exemplo, para journalctl) sobre como obter esses logs.

Algumas outras postagens (por exemploOnde está/por que não há log para serviços normais do usuário do systemd?) parecem indicar que deveria haver mensagens de log como esta:

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.

Mas não vejo essas mensagens de log no meu sistema.

Existe uma maneira de descobrir quando os serviços do systemd foram iniciados, interrompidos ou reiniciados?

Editar: Parece que o problema típico que as pessoas podem enfrentar é que elas executam journalctlcomo usuários não privilegiados. Este não é o meu caso, tenho operado assim rooto tempo todo. Em resposta a um comentário, correr grep systemd /var/log/syslogme dá apenas isto:

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.

Responder1

Se você precisar criar um script, você deve usar o systemctl show comando. É mais útil para scripts do que tentar analisar qualquer coisa do status. Por exemplo, para descobrir quando o serviço foi iniciado pela última vez, você pode usar:

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

Se você quiser ver todas as propriedades disponíveis, basta omitir o sinalizador e todas elas serão descartadas.

$ systemctl show <service_name>

A documentação para essas propriedades pode ser encontradaaqui.

Responder2

Com a configuração padrão no Debian, um usuário sem privilégios não terá acesso ao systemd-journald nem aos logs do syslog. Se estiver logado como usuário normal, você receberá esta resposta do journalctl:

$ journalctl 
No journal files were found.

o que é um pouco confuso.

Se você estiver logado como root, journalctl --unit=yourservicedeverá fornecer as informações que procura. Depois de um systemctl restart bind9no meu servidor, recebo isso depois 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 eu matar bind9 explicitamente com 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.

A primeira linha indica que o processo morreu porque foi eliminado.

O systemd-journald também encaminha todas as mensagens de log para o syslog, portanto, você também deve encontrar essas mensagens no arquivo /var/log/syslog.

Systemd e systemd-journald têm uma configuração padrão compilada que pode ser alterada em /etc/systemd/system.confe /etc/systemd/journald.conf.

Pode ser útil saber que, por padrão, o systemd-journald armazena os logs em /run, que é tmpfs, e, portanto, desaparece após uma reinicialização. Isso significa que, para obter mensagens de log anteriores à última inicialização, você terá que examinar os arquivos syslog. Nesse caso, o journalctl não fornecerá logs anteriores à última inicialização. Isso pode ser alterado /etc/systemd/journald.confconfigurando Storage=persistent.

As páginas de manual que documentam isso são:

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

Observe também que para que um serviço seja reiniciado automaticamente pelo systemd, isso deve estar configurado em seu .servicearquivo. De 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.

Responder3

Você pode ver a última vez que seu serviço foi iniciado ou reiniciado. Utilize service chatty statusou systemctl status chatty. Aqui estão exemplos para serviço apache2 ou 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

a linha Active: active (running) since Wen. 2017-06-02 15:53:01 CEST; 21min agomostra como o serviço está funcionando, mas não sei se você pode exibir como uma 'lista' exatamente o que está procurando.

# 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

informação relacionada