LINUX.ORG.RU
решено ФорумAdmin

systemd запуск сервиса после успешного запуска предыдущего

 


0

1

Всем привет!

Хочется такую функциональность:

Сервис first-стартует при запуске системы
Сервис second-стартует после успешного запуска сервиса first и не ранее!
Если сервис first упал, сервис second останавливается
Если сервис first стартанул снова после падения (это может произойти автоматически через абсолютно рандомное количество времени, т.к. сервис first завязан на железо, которое может отключаться-включаться), то сервис second стартует снова после повторного успешного запуска сервиса first.

Пытался использовать опции:

BindsTo
After
Wants
PartOf

А также изящніе подпорки в виде sleep 30, чтобы сервис second не стартовал раньше, чем успешно включится сервис first, (на этот раз оба сервиса адекватно предоставляют экзит-коды)

Почему они не работают:

PartOf=

Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency — changes to this unit do not affect the listed units.

Т.е. эта опция работает только тогда, когда изменение состояния происходит по воле systemctl restart но не тогда когда главный сервис стартует автоматически.

BindsTo=

Configures requirement dependencies, very similar in style to Requires=. However, this dependency type is stronger: in addition to the effect of Requires= it declares that if the unit bound to is stopped, this unit will be stopped too. This means a unit bound to another unit that suddenly enters inactive state will be stopped too. Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of a mount unit might be unmounted without involvement of the system and service manager.

When used in conjunction with After= on the same unit the behaviour of BindsTo= is even stronger. In this case, the unit bound to strictly has to be in active state for this unit to also be in active state. This not only means a unit bound to another unit that suddenly enters inactive state, but also one that is bound to another unit that gets skipped due to a failed condition check (such as ConditionPathExists=, ConditionPathIsSymbolicLink=, … — see below) will be stopped, should it be running. Hence, in many cases it is best to combine BindsTo= with After=.

Честно говоря, не до конца распарсил, что же именно тут написано, однайко очень похоже на то, что мне нужно. Вот только эффект примерно такой же, как и у предыдущей опции, т.е. вручную рестартуешь юнит-всё ок. Юнит упал и потом поднялся-второй не реагирует, просто стопается и не поднимается. Тут помогает опция Wants. Может, есть какое-то более красивое и правильное решение заместо такой пизанской башни?

intelfx, я выбираю тебя!

★★★★★

Ответ на: комментарий от intelfx

сервис first стартанул снова после падения

Имей в виду, что это само по себе не произойдёт. Тебе нужно что-то, что обработает событие втыкания железа и запустит твой сервис заново. Так, на всякий случай.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ну, это нормально, в системд ничего толком не работает.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.