Як я можу переконатися, що одне завдання Upstart починається перед іншими завданнями Upstart?

Це загальне питання для початківців, але дозвольте мені скористатися конкретним випадком:

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

Це виявилося досить складно досягти, навіть коли намагаються змінити залежності інших служб (що, на мою думку, ми не повинні робити, я не хочу зачіпати інші завдання Upstart, якщо це можливо) .

Пропозиції?

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

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

запустити (починаючи cron або стартуючи autofs або start nis)

Перетворивши це на англійську, це перекладається як:

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

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

Зауважте також, що Upstart заблокує запуск першої служби, яка хоче запуститися до запуску Centrify.

Дуже елегантно і просто, коли ти звикнеш думати таким чином.

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

Сценарій: ви хочете, щоб ваш сервіс A завжди працював перед service-b, service-c і service-d.

Рішення: створити сценарій очікування служби A. Назвіть його "/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. Завдання служби "очікування" призначене для запуску, поки не розпочнеться служба "a". Як тільки служба очікування закінчується, тепер служби b, c і d можуть продовжувати працювати.

Це запевнить, що сервіс-a працює і працює перед спробою запуску будь-якої з його зворотних залежностей.

Примітка: рядок "екземпляр $ JOB" важливий у цьому сценарії "почати з ... або .. або ..". В іншому випадку ви дійсно блокуєте лише те, що починається з B, C або D.

(примірник заслуговує кращого пояснення чесно. поки що просто зробіть це.;)