☰

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

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

Я пытаюсь настроитьГрафитна моем сервере. Я могу запустить демон 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/УСПЕХ)»?Я уже видел неисправные устройства, но это устройство успешно загружено, но не работает, и я не знаю, что это значит.

решение1

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

Как объяснено в man systemd.service:

Если установлено значение forking, ожидается, что процесс, настроенный с помощью ExecStart=, вызовет fork() как часть своего запуска. Ожидается, что родительский процесс завершит работу после завершения запуска и настройки всех каналов связи. Дочерний процесс продолжает работать как основной процесс-демон. Это поведение традиционных демонов UNIX. Если используется этот параметр, рекомендуется также использовать параметр PIDFile=, чтобы systemd мог идентифицировать основной процесс демона. systemd продолжит запуск последующих модулей, как только родительский процесс завершит работу.

Ответ, касающийся графита

Хотя вышеизложенное решило мою проблему с Systemd, я быстро столкнулся с проблемами, специфичными для Graphite (с 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

Связанный контент