Почему systemd останавливает службу сразу после ее запуска?

Question

Я создал службу systemd, которая должна запускать сценарий оболочки при запуске или при перезагрузке.

[Unit]
Description=Starts the DCCA index software

[Install]
WantedBy=multi-user.target

[Service]
ExecStart=/opt/insiteone/bin/indexControl start
ExecStop=/opt/insiteone/bin/indexControl stop

# Execute pre and post scripts as root
#PermissionsStartOnly=true
Restart=on-abort
TimeoutSec=600

изначально он продолжал перезапускаться в бесконечном цикле, как только он был запущен, но когда я добавил опцию TimeoutSec, он вызвал ExecStop, как только сервис был запущен в первый раз (запущен, а затем сразу же снова остановился).

Любая подсказка, где я иду не так? PS: indexControl - это скрипт оболочки, который запускает другие процессы

Answer 1

Вы не сказали systemd, что это за демон и что от него ожидать (главное, чтобы узнать, когда демон наконец запустился).

По умолчанию Type=simple , что означает, что первый процесс считается основным процессом службы. В тот момент, когда он запускается, весь сервис считается «активным (запущенным)»; В момент выхода вся служба останавливается.

Другим распространенным режимом является Type=forking , где начальный процесс, как ожидается, будет разветвлен по крайней мере один раз и завершится, оставив дочерний процесс "в фоновом режиме" или "демонизирован", как некоторые его называют.

Но если вы проходите через инструмент "whatctl", вы всегда будете видеть поведение, которое требует Type=forking, так как сам инструмент попытается запустить демон "в фоновом режиме" и выйти сам.

Answer 2

Ни один из вышеперечисленных и подобных ответов SO не работал для меня. Но этот пост в конце концов сделал.

[Unit]
Description=Setup foo
#After=network.target

[Service]
Type=oneshot
ExecStart=/opt/foo/setup-foo.sh
RemainAfterExit=true
ExecStop=/opt/foo/teardown-foo.sh
StandardOutput=journal

[Install]
WantedBy=multi-user.target

То, что сделал трюк, было директивой RemainAfterExit=true . Это потому, что мой скрипт не оставил никаких следов для просмотра systemd , поэтому следующим шагом systemd всегда был вызов ExecStop чтобы остановить «этот странный скрипт, который не оставляет демона позади». Спорный, но верно.

ОБНОВЛЕНИЕ 20180316: Хорошо, я полностью забыл все о systemd службах за эти несколько месяцев, поэтому я делал всю работу заново. К счастью, я смутно вспомнил об этом ответе, полчаса искал его и теперь я снова здесь.

Я попытаюсь добавить пару вещей, которые я переучил на этот раз: сценарии systemd нельзя размещать в /etc/init , они остаются в более отвратительном каталоге /etc/systemd/system , и они называется .service , а не .conf !

После того, как скрипт находится в правильном каталоге, желательна sudo systemctl daemon-reload , но имя сценария не появится в списке автозаполнения sudo service [TAB] . Тем не менее, новый сервис может быть запущен с:

sudo service myservice start

И это все, теперь сервис делает то, для чего был написан. Конечно, вызываемый скрипт не будет, но это другая проблема.