it-swarm.com.de

Warum ist meine Systemd-Einheit geladen, aber inaktiv (tot)?

Ich versuche, Graphite auf meinem Server einzurichten. Ich kann den Carbon Cache-Daemon problemlos mit Sudo /opt/graphite/bin/carbon-cache.py start Starten, aber ich habe Probleme, ihn als Systemd-Einheit auszuführen.

Folgendes habe ich in meiner Servicedatei: graphite.service:

[Unit]
Description=Carbon for Graphite

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

[Install]
WantedBy=multi-user.target

Aber wenn ich das Gerät starte, erhalte ich folgenden Status:

$ 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 liefert keine weiteren Informationen.

Wie soll ich Einheiten mit dem Status "inaktiv (tot) ... (Code = beendet, Status = 0/ERFOLG)" interpretieren und debuggen? Ich habe schon einmal ausgefallene Einheiten gesehen, aber diese wurde erfolgreich geladen, läuft aber nicht und ich weiß nicht, was das bedeutet.

29
Ryne Everett

Laut jasonwryans Kommentar funktioniert der Standardwert Type=simple Für viele Systemd-Servicedateien, jedoch nicht, wenn das Skript in ExecStart einen anderen Prozess startet und abgeschlossen wird, wie dies beim Carbon-Cache von Graphit der Fall ist. py. In diesen Fällen müssen Sie Type=forking Im Abschnitt [Service] Explizit angeben, damit Systemd den erzeugten Prozess und nicht den ursprünglichen Prozess betrachten kann.

Wie in man systemd.service Erklärt:

Bei der Einstellung Forking wird erwartet, dass der mit ExecStart = konfigurierte Prozess im Rahmen seines Startvorgangs fork () aufruft. Es wird erwartet, dass der übergeordnete Prozess beendet wird, wenn der Start abgeschlossen ist und alle Kommunikationskanäle eingerichtet sind. Das untergeordnete Element wird weiterhin als Hauptdämonprozess ausgeführt. Dies ist das Verhalten traditioneller UNIX-Daemons. Wenn diese Einstellung verwendet wird, wird empfohlen, auch die Option PIDFile = zu verwenden, damit systemd den Hauptprozess des Dämons identifizieren kann. systemd fährt mit dem Starten der Folgeeinheiten fort, sobald der übergeordnete Prozess beendet wird.

Graphitspezifische Antwort

Während das oben genannte mein Systemd-Problem löste, stieß ich schnell auf graphitspezifische Probleme (mit Twisted) und kehrte zum Standardwert Type zurück.

Graphit <0.9.12

In früheren Versionen von Graphite kann man das Gabeln nur mit der Option --debug Vermeiden:

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

Graphit> = 0,9,13

In diese Pull-Anfrage wurde eine --no-daemon Option zusammengeführt:

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