Чому мій блок Systemd завантажений, але неактивний (мертвий)?

Я намагаюся налаштувати Graphite на своєму сервері. Я не можу запустити демон Carbon Cache без проблем sudo /opt/graphite/bin/carbon-cache.py start, але я намагаюся запустити його як блок Systemd.

Ось що я маю у своєму сервісному файлі graphite.service:

[Unit]
Description=Carbon for Graphite

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

[Install]
WantedBy=multi-user.target

Але коли я запускаю пристрій, я отримую такий статус:

$ 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.

Журнал не дає більше інформації.

Як слід інтерпретувати і відладжувати одиниці зі статусом "неактивний (мертвий) ... (код = вийшов, статус = 0 / УСПІХ)"? Я бачив невдалі одиниці раніше, але цей успішно завантажений, але не працює, і я не знаю, що це означає.

systemd

— Райне Еверет
джерело

Це означає, що systemd завершив свою роботу. Чи не повинен бути Type=варіант? Перегляньте man systemd.serviceвідповідний тип.

— jasonwryan

Що має сенс. Все, що я мав зробити, - це додати Type=forkingдо [Service]розділу.

— Ryne Everett

За коментарем jasonwryan, хоча за замовчуванням Type=simpleпрацює для багатьох службових файлів Systemd, він не працює, коли сценарій ExecStartзапускає інший процес і завершує, як це відбувається у графіті carbon-cache.py. У цих випадках потрібно чітко вказати Type=forkingв [Service]розділі, щоб Systemd знав розглядати спарений процес, а не початковий.

Як пояснено в man systemd.service:

Якщо встановлено форкінг, очікується, що процес, налаштований на ExecStart =, викличе fork () як частину його запуску. Очікується, що батьківський процес завершиться після завершення запуску та налаштування всіх каналів зв'язку. Дитина продовжує вести себе як основний процес демона. Така поведінка традиційних демонів UNIX. Якщо використовується цей параметр, рекомендується також використовувати параметр PIDFile =, щоб systemd міг ідентифікувати основний процес демона. systemd перейде до запуску блоків спостереження, як тільки вихідний процес завершиться.

Відповідь, що відповідає графіту

Хоча вищезазначене вирішувало мою проблему з Systemd, я швидко натрапив на специфічні для графіту проблеми (з Twisted) і повернувся до типового Type.

Графіт <0,9.12

У попередніх версіях Graphite можна уникнути розгортання лише за допомогою --debugпараметра:

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

Графіт> = 0,9.13

У цьому запиті на --no-daemonвиклик було об'єднано опцію:

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

— Райне Еверет
джерело