Dlaczego moja jednostka Systemd jest załadowana, ale nieaktywna (martwa)?

Próbuję skonfigurować grafit na moim serwerze. Bez problemu mogę uruchomić demona Carbon Cache sudo /opt/graphite/bin/carbon-cache.py start, ale staram się uruchomić go jako jednostkę Systemd.

Oto, co mam w pliku usługi graphite.service:

[Unit]
Description=Carbon for Graphite

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

[Install]
WantedBy=multi-user.target

Ale kiedy uruchamiam urządzenie, otrzymuję następujący 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 nie daje więcej informacji.

Jak interpretować i debugować jednostki o statusie „nieaktywne (martwe) ... (kod = zakończony, status = 0 / SUKCES)”? Widziałem wcześniej uszkodzone jednostki, ale ta została pomyślnie załadowana, ale nie działa i nie wiem, co to oznacza.

systemd

— Ryne Everett
źródło

Oznacza to, że systemd zakończył pracę. Czy nie powinna istnieć Type=opcja? Sprawdź man systemd.serviceodpowiedni typ.

— jasonwryan

To ma sens. Wszystko, co musiałem zrobić, to dodać Type=forkingdo [Service]sekcji.

— Ryne Everett

Według komentarza jasonwryan, podczas gdy domyślny Type=simpledziała dla wielu plików usługi Systemd, nie działa, gdy skrypt ExecStarturuchamia inny proces i kończy się, jak ma to miejsce w przypadku grafitowego pliku carbon-cache.py. W takich przypadkach należy wyraźnie określić Type=forkingw [Service]sekcji, aby Systemd wiedział, że powinien spojrzeć na odrodzony proces, a nie na proces początkowy.

Jak wyjaśniono w man systemd.service:

Jeśli ustawione na rozwidlenie, oczekuje się, że proces skonfigurowany przy pomocy ExecStart = wywoła fork () jako część jego uruchomienia. Proces nadrzędny powinien zakończyć się po zakończeniu rozruchu i skonfigurowaniu wszystkich kanałów komunikacji. Dziecko nadal działa jako główny proces demona. Jest to zachowanie tradycyjnych demonów UNIX. Jeśli to ustawienie jest używane, zaleca się również użycie opcji PIDFile =, aby systemd mógł zidentyfikować główny proces demona. systemd przystąpi do uruchamiania jednostek kontrolnych, gdy tylko proces macierzysty zakończy działanie.

Odpowiedź specyficzna dla grafitu

Podczas gdy powyższe rozwiązało mój problem Systemd, szybko natknąłem się na problemy specyficzne dla grafitu (z Twisted) i wróciłem do domyślnych Type.

Grafit <0,9.12

W poprzednich wersjach grafitu można uniknąć rozwidlenia tylko poprzez użycie --debugopcji:

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

Grafit> = 0,9.13

W tym wniosku ciągnącej--no-daemon opcja została włączona:

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

— Ryne Everett
źródło