Почему мой модуль Systemd загружен, но не активен (не работает)?

29

Я пытаюсь настроить 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.

Journalctl не дает больше информации.

Как мне интерпретировать и отлаживать модули со статусом «неактивен (мертв) ... (код = выход, статус = 0 / УСПЕХ)»? Я видел сбойные устройства раньше, но этот успешно загружен, но не работает, и я не знаю, что это значит.

systemd Райн Эверетт
источник
4
Это означает, что systemd завершил свою работу. Не должно ли быть Type=вариант? Смотрите man systemd.serviceдля соответствующего типа.
Джейсонвриан
1
В этом есть смысл. Все, что мне нужно было сделать, это добавить Type=forkingв [Service]раздел.
Райн Эверетт

Ответы:

26

Согласно комментарию 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
Райн Эверетт
источник