Как я могу убедиться, что одно задание Upstart запускается перед другими заданиями Upstart?

Это общий вопрос Upstart, но позвольте мне использовать конкретный случай:

Centrify - это шлюз от NIS к ActiveDirectory. Он должен загружаться перед любой службой, которая будет зависеть от службы аутентификации, которую он предоставляет, например, autofs, cron, nis и др.

Это оказалось довольно сложной задачей, даже при попытке изменить зависимости других сервисов (что я не думаю, что мы должны делать в любом случае, я не хочу касаться других заданий Upstart, если это вообще возможно) ,

Предложения?

Решение состоит в том, чтобы подойти к проблеме с другой стороны: чтобы удовлетворить начальные критерии для Centrify, нет необходимости ставить существующие службы в зависимость от новой службы Centrify, скорее, чтобы новая служба Centrify зависела от существующих служб.

Например, файл конфигурации Upstart /etc/init/centrify.confможет сказать:

начать с (запуск cron или запуск autofs или запуск nis)

Если перевести это на английский, это будет выглядеть так:

Запустите службу Centrify непосредственно перед запуском cron, autofs или nis (в зависимости от того, что запускается первым).

Порядок, в котором запускаются cron, autofs или nis, не имеет значения: Upstart гарантирует, что Centrify запустится до того, какой сервис запустится первым, тем самым гарантируя, что Centrify будет запущен до запуска любой из этих служб.

Также обратите внимание, что Upstart будет блокировать запуск первой службы, которая хочет запускаться, пока Centrify не запустится.

Очень элегантно и просто, если привыкнуть к такому мышлению.

Ответ Джеймса работает для зависимости 1: 1. Для того чтобы 1 к многим, т. Е. Чтобы убедиться, что служба A запускается до служб B, C и D, вам необходимо использовать другой подход. Вы можете посмотреть на текущие сценарии portmap для справки, но вот общий подход: создайте сценарий ожидания.

Сценарий: вы хотите, чтобы служба A всегда работала до service-b, service-c и service-d.

Решение: создайте сценарий ожидания для службы А. Назовите его «/etc/init/service-a-wait.conf»

# service-a-wait

start on (starting service-b 
    or starting service-c
    or starting service-d)
stop on (started service-a or stopped service-a)

# We know that we have more than one job that needs to wait for service-a and
# will make use of this service, so we need to instantiate.
instance $JOB

# Needed to make starting the job successful despite being killed
normal exit 2
task

script

    status service-a | grep -q "start/running" && exit 0
    start service-a || true

    # Waiting forever is ok.. upstart will kill this job when
    # the service-a we tried to start above either starts or stops
    while sleep 3600 ; do :; done

end script

Это означает, что на простом английском языке: когда служба b, c или d сигнализирует о своем желании запустить, они должны дождаться запуска, пока не будет запущена служба a. Задание обслуживания до ожидания предназначено для запуска до тех пор, пока не будет запущено обслуживание. После выхода из режима ожидания обслуживания теперь сервисы b, c и d могут продолжать работать и работать.

Это гарантирует, что service-a запущена и работает до того, как попытается запустить любую из его обратных зависимостей.

Примечание: строка «instance $ JOB» важна в этом сценарии «start on ... or .. or ..». В противном случае вы действительно заблокируете только тот, который из B, C или D сработает первым.

(Инстанциация заслуживает лучшего объяснения, если честно. Пока просто сделайте это;)