Описание параметра systemd «Requires =»
Это будет:
for i in {1..3}; do
mkdir dir$i
touch dir$i/file1
date > dir$i/file2
if [ $i -eq 3 ]; then
grep $(hostname) /etc/hosts > dir$i/file3
fi
done
Это сложно. Главное понять, что systemd запускает все параллельно, если только не сказано не делать этого. На самом деле это указано на странице руководства в разделе «Требуется» :
.requirement dependencies do not influence the order in which services are started or stopped
Чего вы хотите добиться, так это «подождать, пока будет запущена служба , прежде чем запустить b.service». Для этого вам нужны обе опции «Требуется» и «После» в вашем файле b.service :
.[Unit]
Requires=a.service
After=a.service
[Service]
ExecStart=/bin/sleep 1000
= ОБНОВЛЕНИЕ =
Хорошо, я понимаю, что не так :в вашем файле a.service вы указали команду ExecStart и не указали тип. Это означает, что для Типа по умолчанию будет установлено значение «Простой». Для этого вам нужен тип «Разветвление». Со страницы руководства systemd.service:
If set to simple (the default if neither Type= nor BusName=, but ExecStart= are specified), it is expected that the process configured with ExecStart= is the main process of the service. In this mode, if the process offers functionality to other processes on the system, its communication channels should be installed before the daemon is started up (e.g. sockets set up by systemd, via socket activation), as systemd will immediately proceed starting follow-up units.
If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can identify the main process of the daemon. systemd will proceed with starting follow-up units as soon as the parent process exits.
Поэтому вам следует обновить файл a.service, включив в него «Type=Forking»:
[Service]
Type=forking
ExecStart=/bin/false
Это сработает.:)
Если вы используете CentOS 7 с systemd -219 (, у которой есть справочная страница systemd.unit(5), соответствующая разделу, указанному в вопросе ), это может быть частично связано с ошибкой документации. Возможно, то же самое относится и к некоторым другим дистрибутивам и версиям systemd.
Это предложение процитировано в комментарии:
If one of the other units gets deactivated or its activation fails, this unit will be deactivated.
подсказал мне, что systemctl start b.serviceвызовет активацию обеих служб, но после того, как a.serviceпотерпит неудачу при возвращении из /bin/false, b.serviceбудет автоматически деактивирован. Так же, как в вопросе говорится, что это не наблюдаемое поведение, я не наблюдал такого поведения в CentOS 7.
Цитируемое предложение было заменено этими предложениями вhttps://www.freedesktop.org/software/systemd/man/systemd.unit.html:
If one of the other units fails to activate, and an ordering dependency After= on the failing unit is set, this unit will not be started. Besides, with or without specifying After=, this unit will be stopped if one of the other units is explicitly stopped.
Обновленная документация согласуется с заявлением @gerard о том, что вам нужна настройка After=в b.service, и соответствует поведению, которое я наблюдал в CentOS 7.
Затем, как говорит @gerard, когда systemd запускает службу Type=simple, она «немедленно продолжит запуск последующих -единиц». Обратите внимание, что Type=forking— не единственный параметр, который можно использовать для решения этой проблемы, вы также можете установить Type=notifyили один из других типов, описанных на справочной странице systemd.service(5)(, кромеType=idle). Когда вы прошли этап тестирования обработки сбоев, убедитесь, что служба действительно ведет себя так, как требуется, учитывая ее Type, например. он вызывает fork(), sd_notify()и т. д.
Также имейте в виду, что существует множество пограничных случаев при обработке сбоев в systemd -219, например.https://github.com/systemd/systemd/issues/8398