От init.d до upstart есть ли мост?

Я думал, что Upstart поддерживает обратную совместимость со сценариями инициализации в стиле SysV в /etc/init.d. Вы должны иметь возможность использовать ваши сценарии инициализации без изменений.

Так что одним из пунктов выскочки является простота написания.

В сценариях init.d много магии сценариев оболочки, которые повторяются снова и снова. Операторы case, отслеживание pidfile, строки комментариев lsb. Не очень понятно, как написать ХОРОШИЙ скрипт init.d, не прочитав его.

Если вы уже столкнулись с трудностями при написании всего этого, то вам не нужна выскочка, если, как я уже упоминал в другом комментарии, вы не зависите от другой выскочки / события.

Но на самом деле выскочка делает вещи действительно простыми. Вам не нужно предварительно запускать, если вам не нужно настраивать такие вещи, как tmpdirs, ulimits или аргументы времени выполнения. Вы не должны нуждаться в пост-остановке, если не хотите убедиться, что вы убираете после службы (служба действительно должна убирать за собой при нормальном выходе).

Часто гигантский сценарий init.d со множеством опций сводится к 10-15-строчкам. У самых сложных сценариев init.d большая часть их логики может быть выгружена в предстартовые. Ключевым моментом здесь является то, что это всего лишь небольшой фрагмент кода для настройки среды для процесса, а не логика обработки start / stop / respawn / etc.

Самое сложное, и то, что люди чаще всего ошибаются, это знать, когда начинать / прекращать свою работу. start on runlevel [2345] кажется логичным, но игнорирует тот факт, что в этот момент сеть работает параллельно, как и монтирования локальной файловой системы. Ключ в том, чтобы попытаться определить, какие именно минимальные ресурсы вам нужны (другие сервисы, файловые системы, сеть и т. Д.) Для запуска, и начать, когда это будет сделано. Большинство традиционных сетевых служб должны делать start on (local-filesystems and net-device-up IFACE!=lo).

Я не помню, чтобы видел шаблон для этого. Немного иронично, однако, что технически это выскочка, которая в первую очередь запускает ваш скрипт init.d благодаря заданию обратной совместимости rc и rcS.

Я бы рассмотрел возможность переписать все, что у вас есть, в качестве выскочки, однако я знаю, что некоторые сценарии трудно конвертировать, поэтому вот что я сделал на некоторых из моих сценариев:

description "xyz"
author "xyz"
start on runlevel 5
stop on runlevel [!5]

pre-start script
    # do my work here to start the service
end script

post-stop script
    # do work here to stop the service
end script

Теперь, в зависимости от характера службы, от того, сохраняется она или разветвляется, вам может потребоваться добавить expect fork или task в файл задания.

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

exec service_cmd