☰

¿Por qué mi unidad Systemd está cargada, pero inactiva (muerta)?

tag-icon • tag-icon systemd
¿Por qué mi unidad Systemd está cargada, pero inactiva (muerta)?

Estoy intentando configurarGrafitoen mi servidor. Puedo iniciar el demonio Carbon Cache sin problemas sudo /opt/graphite/bin/carbon-cache.py start, pero tengo dificultades para ejecutarlo como una unidad Systemd.

Esto es lo que tengo en mi archivo de servicio graphite.service:

[Unit]
Description=Carbon for Graphite

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py start

[Install]
WantedBy=multi-user.target

Pero cuando inicio la unidad obtengo el siguiente estado:

$ systemctl status graphite.service            
* graphite.service - Carbon for Graphite
   Loaded: loaded (/etc/systemd/system/graphite.service; enabled)
   Active: inactive (dead) since Fri 2014-06-13 18:44:11 UTC; 2s ago
  Process: 4525 ExecStart=/opt/graphite/bin/carbon-cache.py start (code=exited, status=0/SUCCESS)
 Main PID: 4525 (code=exited, status=0/SUCCESS)

Jun 13 18:44:11 MEADOW systemd[1]: Started Carbon for Graphite.

Journalctl no proporciona más información.

¿Cómo debo interpretar y depurar unidades con un estado de "inactivo (muerto)...(código=salido, estado=0/ÉXITO)"?He visto unidades fallidas antes, pero ésta se cargó exitosamente pero no se ejecuta y no sé qué significa eso.

Respuesta1

Según el comentario de Jasonwryan, si bien el valor predeterminado Type=simplefunciona para muchos archivos de servicio Systemd, no funciona cuando el script ExecStartinicia otro proceso y se completa, como es el caso de carbon-cache.py de Graphite. En estos casos, debe especificar explícitamente Type=forkingen la [Service]sección para que Systemd sepa que debe mirar el proceso generado en lugar del inicial.

Como se explica en man systemd.service:

Si se configura en bifurcación, se espera que el proceso configurado con ExecStart= llame a fork() como parte de su inicio. Se espera que el proceso principal finalice cuando se complete el inicio y se configuren todos los canales de comunicación. El niño continúa ejecutándose como el proceso demonio principal. Este es el comportamiento de los demonios UNIX tradicionales. Si se utiliza esta configuración, se recomienda utilizar también la opción PIDFile=, para que systemd pueda identificar el proceso principal del demonio. systemd procederá a iniciar las unidades de seguimiento tan pronto como finalice el proceso principal.

Respuesta específica de grafito

Si bien lo anterior resolvió mi problema de Systemd, rápidamente me encontré con problemas específicos de grafito (con Twisted) y terminé volviendo al valor predeterminado Type.

Grafito < 0.9.12

En versiones anteriores de Graphite solo se puede evitar la bifurcación usando la --debugopción:

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py --debug start

Grafito >= 0.9.13

Enesta solicitud de extracción--no-daemonse fusionó una opción:

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py --no-daemon start

información relacionada