Служба может стоять в очереди и ждать другого юнита. При загрузке так ждут друг друга десятки служб, а увидеть ожидание можно и на работающей машине — в очереди запусков systemd.
Посмотри, чего ждёт служба
Службу отчётов lab-report только что запустили, а отчёты она не отдаёт. Посмотри очередь запусков systemd, состояние lab-report и файл её юнита.
Сначала предположи
lab-report запустили командой systemctl start, а её процесса нет. Что покажет очередь запусков systemctl list-jobs?
Теперь начни упражнение, выполни команду и сверь прогноз с выводом.
В файле юнита два вида связей (в Вики). Порядок запуска задают After= и Before=: «если оба юнита запускаются, этот стартует после того». Сам по себе After= другой юнит не запускает. Зависимость задают Wants= и Requires=: «запусти вместе со мной и тот юнит». Разница — в отказе: с Wants= служба стартует, даже если тот юнит упал, с Requires= (и After= на тот же юнит) — не стартует, и в журнале появится Dependency failed.
Обычно пишут пару: Wants= и After= — «запусти и дождись». Так устроена lab-report: Wants= запустил lab-cache, а After= держит lab-report в очереди, пока lab-cache не закончит. Без After= обе службы стартовали бы одновременно. Очередь показывает systemctl list-jobs: running — задание выполняется, waiting — ждёт других.
lab-cache упала при запуске. Что будет с lab-report, если в её юните вместо Wants= стоит Requires=lab-cache.service (а After= — как было)?
-
Так ведёт себя
Wants=: служба стартует и после отказа. СRequires=systemd отменяет запуск:systemctl startответит A dependency job … failed. -
Ждёт служба, пока lab-cache запускается. Когда lab-cache упала, ждать больше нечего: с
Requires=задание lab-report отменяется.
Requires= — жёсткая зависимость: не запустился тот юнит — не запускается и этот, а в журнале — Dependency failed for lab-report.service. С Wants= lab-report стартовала бы и после отказа lab-cache.