systemctl + что означает Restart=always
Я столкнулся с проблемой, когда мне нужно было, чтобы мой сценарий выскочки ждал сокета libvirt-bin, так как вы не можете просто использовал start на запущенном libvirt-bin из-за этой ошибки .
В любом случае, я закончил свой сценарий выскочки так:
start on socket PROTO=unix SOCKET_PATH=/var/run/libvirt/libvirt-sock
task
exec /data/configureESA.sh
Согласно документации , на которую ссылается @sr _:
Событие сокета генерируется upstart-socket-bridge (8) демон , когда выполняется соединение через сокет, детали которого соответствуют условию события сокета и среде, указанной в задании, запускаются или останавливаются в разделе .
запуск на сокете PROTO = inet PORT = 80 ADDR = 127.0.0.1
запуск на сокете PROTO = unix SOCKET_PATH = / var / run / .s.pgsql.1234
запуск на сокете PROTO = unix SOCKET_PATH = @ / at / upstart / example
@JdeBP предложил другой способ взглянуть на этот вопрос.
Restart=alwaysпроще. Легче реализовать, легче понять. Зачем нам когда-либо проверять, завершилась ли служба с кодом выхода 0 (EXIT_SUCCESS)? Возможно, в службе даже была странная ошибка / ошибка, из-за которой она завершалась с кодом выхода 0, когда этого не следовало делать.
Ответ 1 :Некоторые устройства не должны использовать Restart=always. В частности, если служба завершает работу после тайм-аута простоя.
Любопытно, что это не имело бы большого значения, если бы баг/ошибка приводила к "успешному завершению" такой службы, хотя этого делать не следовало. Поскольку тайм-аут простоя подразумевает, что служба уже настроена на автоматический запуск при поступлении нового запроса.
Однако Restart=on-failureможет использоваться для службы, которая может выходить из режима ожидания в одних конфигурациях, но не в других.systemd-networkdиспользует его по этой причине .
Ответ 2 :Практика системного администрирования может включать уничтожение или обмен сообщениями сервисных процессов для их остановки. Иногда люди используют простую команду kill, но есть и такие скрипты, как apachectl. Преимущество Restart=on-failureзаключается в том, что systemdменее рискованно рекомендовать использовать его (, как это делает справочная страница ).
Однако systemdостается в странном положении, когда они также поддерживают Restart=always, и это то, что они любят устанавливать для большинства долго -запущенных сервисов внутри проекта systemd... Это не кажется очень полезным, когда вы пытаетесь узнать об определениях службы systemd.