Tengo un servicio (escrito por mí) ejecutándose en un servidor Debian (Jessie) y los propios registros del servicio indican que se reinició en un momento determinado. No hay indicios de un error de segmentación u otro bloqueo, por lo que ahora estoy tratando de averiguar si la aplicación de alguna manerasilenciosamentefalló y systemd lo reactivó, o si un usuario reinició intencionalmente el servicio a través de systemctl.
El historial del shell no muestra dicha actividad, pero eso no es concluyente debido a export HISTCONTROL=ignorebothque es posible que se haya agotado el tiempo de espera de una sesión SSH, lo que impide 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 el propio systemd mantuviera un registro que indicara cuándo se lanzó un servicio.a propósitoreiniciado. 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 ningún registro para los servicios systemd del usuario normal?) 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 esos 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 se puede encontrar la gente es que se ejecuta journalctlcomo un usuario sin privilegios. Este no es mi caso, he estado operando así roottodo el tiempo. En respuesta a un comentario, ejecutar 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.
Respuesta1
Si necesita escribir esto, debería considerar el uso del systemctl show
comando. Es más útil para scripts que intentar analizar cualquier cosa desde status. Por ejemplo, para saber cuándo se inició el servicio por última vez, puede utilizar:
$ 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 encontraraquí.
Respuesta2
Con la configuración predeterminada en Debian, un usuario sin privilegios no tendrá acceso ni al systemd-journald ni a los registros de syslog. Si inicia 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 proporcionarle la información que busca. Después de a systemctl restart bind9en mi servidor, aparece esto después 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=bind9obtengo:
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 deberías encontrar estos mensajes en /var/log/syslog.
Systemd y systemd-journald tienen una configuración compilada predeterminada que se puede cambiar en /etc/systemd/system.confy /etc/systemd/journald.conf.
Puede resultar útil saber que, de forma predeterminada, systemd-journald almacena los registros en /run, que es tmpfsy, por lo tanto, desaparece después de reiniciar. Esto significa que para obtener mensajes de registro anteriores al último inicio, deberá examinar los archivos syslog. En este caso, journalctl no le proporcionará registros anteriores al último inicio. 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 systemd reinicie un servicio automáticamente, 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.
Respuesta3
Puede ver la última vez que se inició o reinició su servicio. Utilice service chatty statuso systemctl status chatty. A continuación se muestran ejemplos del 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