☰

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

tag-icon • tag-icon systemd
Warum ist meine Systemd-Einheit geladen, aber inaktiv (tot)?

Ich versuche einzurichtenGraphitauf meinem Server. Ich kann den Carbon Cache-Daemon problemlos starten sudo /opt/graphite/bin/carbon-cache.py start, habe aber Probleme, ihn als Systemd-Einheit auszuführen.

Folgendes steht 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 den 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/ERFOLGREICH)“ interpretieren und debuggen?Ich habe schon früher ausgefallene Einheiten gesehen, aber diese wurde erfolgreich geladen, läuft jedoch nicht, und ich weiß nicht, was das bedeutet.

Antwort1

Laut Jasonwryans Kommentar Type=simplefunktioniert die Standardeinstellung zwar für viele Systemd-Servicedateien, aber nicht, wenn das Skript ExecStarteinen anderen Prozess startet und abgeschlossen wird, wie dies bei Graphites carbon-cache.py der Fall ist. In diesen Fällen müssen Sie dies Type=forkingim [Service]Abschnitt explizit angeben, damit Systemd weiß, dass es den gestarteten Prozess und nicht den ursprünglichen Prozess betrachten soll.

Wie erklärt in man systemd.service:

Wenn auf Forking eingestellt, wird erwartet, dass der mit ExecStart= konfigurierte Prozess beim Start fork() aufruft. Der übergeordnete Prozess wird voraussichtlich beendet, wenn der Start abgeschlossen ist und alle Kommunikationskanäle eingerichtet sind. Der untergeordnete Prozess wird weiterhin als Haupt-Daemon-Prozess 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 Daemons identifizieren kann. systemd wird mit dem Starten nachfolgender Einheiten fortfahren, sobald der übergeordnete Prozess beendet ist.

Graphitspezifische Antwort

Während das oben genannte mein Systemd-Problem löste, stieß ich schnell auf Graphit-spezifische Probleme (mit Twisted) und bin schließlich zur Standardeinstellung zurückgekehrt Type.

Graphit < 0,9,12

In früheren Versionen von Graphite konnte eine Aufspaltung nur durch die Verwendung der folgenden --debugOption vermieden werden:

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

Graphit >= 0.9.13

Indieser Pull Requesteine --no-daemonOption wurde zusammengeführt:

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

verwandte Informationen