Perché la mia unità Systemd è caricata, ma inattiva (morta)?


29

Sto cercando di configurare Graphite sul mio server. Posso avviare il demone Carbon Cache senza problemi sudo /opt/graphite/bin/carbon-cache.py start, ma faccio fatica a eseguirlo come unità Systemd.

Ecco cosa ho nel mio file di servizio graphite.service:

[Unit]
Description=Carbon for Graphite

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

[Install]
WantedBy=multi-user.target

Ma quando avvio l'unità ottengo il seguente stato:

$ 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 non fornisce ulteriori informazioni.

Come devo interpretare ed eseguire il debug di unità con uno stato di "inattivo (morto) ... (codice = uscito, stato = 0 / SUCCESSO)"? Ho già visto unità guaste, ma questa è stata caricata correttamente ma non è in esecuzione e non so cosa significhi.


4
Significa che systemd ha completato il suo lavoro. Non dovrebbe esserci Type=un'opzione? Vedere man systemd.serviceper un tipo appropriato.
Jasonwryan,

1
Ciò ha senso. Tutto quello che dovevo fare era aggiungere Type=forkingalla [Service]sezione.
Ryne Everett,

Risposte:


26

Secondo il commento di Jasonwryan, mentre il valore predefinito Type=simplefunziona per molti file di servizio Systemd, non funziona quando lo script in ExecStartavvia un altro processo e si completa, come nel caso del carbon-cache.py della grafite. In questi casi è necessario specificare esplicitamente Type=forkingnella [Service]sezione in modo che Systemd sappia esaminare il processo generato anziché quello iniziale.

Come spiegato in man systemd.service:

Se impostato su fork, si prevede che il processo configurato con ExecStart = chiamerà fork () come parte del suo avvio. Il processo padre dovrebbe terminare quando l'avvio è completo e tutti i canali di comunicazione sono impostati. Il bambino continua a essere eseguito come processo daemon principale. Questo è il comportamento dei demoni UNIX tradizionali. Se si utilizza questa impostazione, si consiglia di utilizzare anche l'opzione PIDFile =, in modo che systemd possa identificare il processo principale del daemon. systemd procederà con l'avvio delle unità di follow-up non appena termina il processo padre.

Risposta specifica per la grafite

Mentre quanto sopra risolto il mio problema di Systemd, ho subito riscontrato problemi specifici di grafite (con Twisted) e sono tornato al valore predefinito Type.

Grafite <0.9.12

Nelle versioni precedenti di Graphite si può solo evitare il fork utilizzando l' --debugopzione:

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

Grafite> = 0.9.13

In questa richiesta di pull un --no-daemonopzione è stata fusa:

[Service]
ExecStart=/opt/graphite/bin/carbon-cache.py --no-daemon start
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.