¿Cómo veo cuando se inició / detuvo / reinició un servicio systemd?

12

Tengo un servicio (escrito por mí mismo) que se ejecuta en un servidor Debian (Jessie), y los registros del servicio indican que se reinició en un momento determinado. No hay indicios de un fallo de seguridad u otro bloqueo, por lo que ahora estoy tratando de averiguar si la aplicación falló de alguna manera silenciosa y fue reaparecida por systemd, o si un usuario reinició el servicio a propósito systemctl.

El historial de shell no muestra dicha actividad, pero eso no es concluyente debido a export HISTCONTROL=ignorebothque una sesión SSH podría haberse agotado, evitando que el historial de bash de un inicio de sesión anterior se escriba en el disco. El servidor no se reinició en ese momento.

Pero esperaría que systemd mismo mantenga un registro que indique cuándo se reinició un servicio a propósito . Para mi sorpresa, no pude encontrar ninguna documentación (por ejemplo, para journalctl) sobre cómo obtener dichos registros.

Algunas otras publicaciones (por ejemplo, ¿Dónde está / por qué no hay registro para los servicios normales de systemd de usuario? ) Parecen indicar que debería haber mensajes de registro como este:

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.

Pero no veo tales mensajes de registro en mi sistema.

¿Hay alguna manera de saber cuándo se iniciaron, detuvieron o reiniciaron los servicios systemd?

Editar : Parece que el problema típico con el que las personas pueden encontrarse es que se ejecutan journalctlcomo usuarios sin privilegios. Este no es el caso para mí, he estado operando roottodo el tiempo. En respuesta a un comentario, correr grep systemd /var/log/syslogsolo me da esto:

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.
systemd  systemd-journald 
— mindriot
fuente
"no veo tales mensajes de registro" - extraño? Tengo mucho engrep systemd /var/log/syslog
— hschou
En mi sistema solo veo mensajes muy genéricos como Stopped target Default, Starting Shutdownetc. Nada que indique algo sobre servicios individuales. ¿Quizás es solo un problema de configuración? Tenga en cuenta que estoy en Debian Jessie en este caso particular.
— mindriot
Compruebe que /etc/systemd/journald.confno se ha anulado MaxLevelStoreo MaxLevelSyslog, y busque en todos los otros lugares donde puede configurar journald como se enumera en man journald.conf.
— meuh
Gracias por el consejo. Desafortunadamente, todos los archivos de configuración ubicados debajo /etc/systemdestán esencialmente vacíos (todas las opciones comentadas, incluidas las que mencionó).
— mindriot

Respuestas:

11

Si necesita hacer un script para esto, debe considerar el uso del systemctl show comando. Es más útil para los scripts que intentar analizar cualquier cosa status. Por ejemplo, para saber cuándo se inició el servicio por última vez, puede usar:

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

Si desea ver todas las propiedades disponibles, simplemente omita la bandera y las eliminará todas.

$ systemctl show <service_name>

La documentación de estas propiedades se puede encontrar aquí .

— jdf
fuente
Interesante, no estaba al tanto de las propiedades. Desafortunadamente, se configuran de la misma manera, independientemente de si el servicio falló y reapareció, o si el servicio fue reiniciado a propósito por un usuario.
— mindriot
1
Por cierto, un mejor enlace para las propiedades parece ser la documentación de dbus .
— mindriot
Gracias @mindriot que es un mejor enlace para documentos, he actualizado mi respuesta.
— jdf
1
@mindriot con respecto a su primer punto, ¿ha verificado StatusErrnoy Result? Me pregunto si esos cambian si el servicio falla o se reinicia. Si realmente necesita ir más allá, intente agregar un ExecStopPostpaso donde toque un archivo y actualice una marca de tiempo al apagar. Eso lo ayudará a diferenciar entre los reinicios silenciosos y los resueltos.
— jdf
Gracias, ese también es un buen punto. No podré verificar / reproducir la situación fácilmente; mi publicación original ya tiene casi medio año y desde entonces hemos tenido algunos cambios en el sistema. Sin embargo, comprobaré si puedo probarlo en algún lugar, si tengo la oportunidad.
— mindriot
3

Con la configuración predeterminada en Debian, un usuario sin privilegios no tendrá acceso a los registros systemd-journald ni syslog. Si inició sesión como usuario normal, recibirá esta respuesta de journalctl:

$ journalctl 
No journal files were found.

lo cual es un poco confuso.

Si ha iniciado sesión como root, journalctl --unit=yourservicedebería darle la información que está buscando. Después de un systemctl restart bind9en mi servidor, obtengo esto después de 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.

Si mato a bind9 explícitamente con kill -9, journalctl --unit=bind9da:

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 primera línea indica que el proceso murió porque fue asesinado.

systemd-journald también reenvía todos los mensajes de registro a syslog, por lo que también debe encontrar estos mensajes en /var/log/syslog.

Systemd y systemd-journald tienen una configuración predeterminada compilada que se puede cambiar en /etc/systemd/system.confy /etc/systemd/journald.conf.

Puede ser útil saber que, por defecto, systemd-journald almacena los registros /run, lo cual es tmpfs, y por lo tanto desaparece después de un reinicio. Esto significa que para obtener mensajes de registro más antiguos que el último arranque, tendrá que mirar los archivos syslog. En este caso, journalctl no le dará registros más antiguos que el último arranque. Esto se puede cambiar /etc/systemd/journald.confconfigurando Storage=persistent.

Las páginas del manual que documentan esto son:

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

También tenga en cuenta que para que un servicio sea reiniciado automáticamente por systemd, esto debe configurarse en su .servicearchivo. 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.
— Tom Bjerck
fuente
Gracias por la publicación extensa y bien escrita que probablemente resuelva el problema para la mayoría de los usuarios. Desafortunadamente, en mi caso no veo ninguna línea de registro atribuida a la systemdsalida del diario como usted describió, a pesar de que he trabajado como root todo el tiempo. /var/log/syslogtampoco muestra nada. Esto es systemd 215 por cierto.
— mindriot
3

Puede ver la última vez que su servicio se inició o reinició. Use service chatty statuso systemctl status chatty. Aquí hay ejemplos para el servicio 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 línea Active: active (running) since Wen. 2017-06-02 15:53:01 CEST; 21min agomuestra cómo se está ejecutando el servicio, pero no sé si puede mostrar como una "lista" exactamente lo que está buscando.

# 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
fuente
1
servicees un antiguo comando Upstart que funciona con systemd para compatibilidad. El systemdcomando nativo es systemctl status apache2.
— Mark Stosberg
Gracias. Desafortunadamente, solo se muestra cuando se (re) inició el servicio, pero no por qué ; y también solo muestra la situación actual , es decir, el último reinicio.
— mindriot
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.