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

33

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

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

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

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

boot upstart init Марк Рассел
источник

Ответы:

29

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

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

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

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

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

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

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

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

Джеймс Хант
источник
4
это кажется полностью отсталым для меня. почему скрипт conf для одного сервиса должен быть изменен, если от этого зависят другие вещи ?
Бен Вт
3
@benw Чтобы вам не пришлось изменять существующие настройки служб, которыми вы не владеете.
Paccc
1
@Paccc, когда я пишу новый скрипт, который зависит от nginx, я должен изменить скрипт conf для nginx ... который мне не принадлежит.
Бен с
2
@benw Почему вы не можете использовать start on (started nginx)в своем новом скрипте?
Paccc
2
@Paccc не совсем. start on (started nginx)означает «запустить мой сервис после nginx». Это не то же самое, что «запустить nginx перед моим сервисом, потому что это нужно».
серп
12

Ответ Джеймса работает для зависимости 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 сработает первым.

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

Марк Рассел
источник
3
Я не понимаю ... что мешает состязанию между запуском службы A и продолжением запуска службы B? Я не понимаю, как выскочка узнает, что сценарий выполнил "start service-a" ... (возможно, в этом виновата
скудная
@ Марк Рассел: Разве эта normal exit 2линия не должна быть normal exit 0 2вместо этого? Первая строчка в scriptразделе вполне понятно может exit 0.
августа