Я видел рецепты сборки, которые строят supervisor в конструкцию, я полагаю, чтобы управлять демонами внутри. Однако мне кажется, что в файле /etc/init.d (например) все-таки потребуется что-то, чтобы запустить указанный экземпляр супервизора при загрузке.Зачем строить надзор внутри внутри здания?
Итак, зачем строить супервизор внутри сборки? Почему бы не установить его в системном виде и просто создать файл конфигурации для демонов, участвующих внутри?
Когда мы создаем сборку для клиента, мы хотим, чтобы эта сборка выполнялась в произвольных средах хостинга с минимальными зависимостями, которые удовлетворяют системным пакетам. Включая супервизор в сборку, мы исключаем необходимость его установки в системе и можем точно настроить его параметры, не требуя от администратора системы изменить настройки для нас.
Это легко получить супервизор во время загрузки из билдаута, используя рецепт usercrontab:
[supervisor-cron]
recipe = z3c.recipe.usercrontab
times = @reboot
command = ${buildout:bin-directory}/supervisord -c ${buildout:directory}/etc/supervisord.conf
выше часть будет добавить запись в кронтаб, который вызывает супервизор для запуска во время загрузки.
Полностью согласен. @reboot cronjob, который запускает супервизор, означает настройки нулевого обслуживания. Прекрасно работает. –
* Похлопывает себя за то, что забыл о crontab * Мне ясно, почему это делается, и я также полностью согласен. Спасибо. – chiggsy
Проблема возникает, когда вы * не хотите этого делать * и хотите, чтобы рецепт, который просто выплескивает действительную конфигурацию программы-диспетчера 9 (ов). Я еще не смог найти такой рецепт. –