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

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

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

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

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

33
задан 26 March 2011 в 03:16

2 ответа

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

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

start on (запуск cron или запуск autofs или запуск nis)

Преобразование этого в По-английски это можно перевести как:

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

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

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

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

0
ответ дан 26 March 2011 в 03:16

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

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

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

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

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

0
ответ дан 26 March 2011 в 03:16

Другие вопросы по тегам:

Похожие вопросы: