А вопрос возник на StackOverflow спрашивать о написании init.d скрипты на Python. В одном из комментариев указывалось, что эти сценарии следует программировать в оболочке, а не в Python. Пишет init.d скрипты на Python:
Было бы здорово узнать какие-нибудь кошмарные сценарии, или написано ли это правило кровью какого-то сисадмина.
Я не вижу в этом проблемы, если вы точно знаете, что интерпретатор Python будет доступен при запуске скрипта init.d. Для меня это означает, что вы смотрите на что-то, что делается относительно поздно в многопользовательском (или «графическом») уровне выполнения.
Однако ... Это означает, что конкретная версия интерпретатора Python МОЖЕТ быть жизненно важной для вашей последовательности загрузки, и это еще одна вещь, которую вам нужно проверять при обновлении.
Думаю, это означает, что я говорю: «3. Хорошо, с оговорками».
Я бы сказал №2, но очень близко к №1 - «Плохо. Плохо. Плохо. Никогда не делай этого». Стандарт, такой как он есть, для сценариев инициализации Linux - в младшем разряде, и хотя он никогда не выходит и говорит, что «это сценарии оболочки Bourne», сделано несколько предположений. Первый, что строки, начинающиеся с #, являются комментариями, получается нормально. Более проблематичным является требование, чтобы сценарий инициализации выполнял команды из /lib/lsb/init-functions "в текущей среде (см. специальную встроенную командную точку оболочки)".
Но что еще более важно, если вы делаете здесь что-то действительно сложное, значит, вы делаете это неправильно. Скрипты инициализации должны быть очень простыми и утилитарными. Это должны быть сценарии в классическом понимании, а не программы. Лучше впитывать его и создать простой сценарий оболочки, который любой системный администратор может легко разобрать одним быстрым взглядом, чем создавать что-то красивое и спроектированное на Python.
Еще одно соображение, о котором следует помнить: systemd, который может быть или не быть будущим инициализации всей системы в Linux. В systemd инициализация выполняется с помощью простых файлов конфигурации, а не сценариев, идея состоит в том, что весь запуск соответствует нескольким стандартным шаблонам проектирования, и вам нужно просто выбрать один. Если ваша программа использует что-то сложное для инициализации, это должно выходить за рамки самого сценария инициализации.
Я согласен с «3. Хорошо, с оговорками», но по другим причинам. Мой опыт работы с Solaris показал, что у них была копия Perl для некоторых из своих внутренних программ. Сценарий оболочки был не чем иным, как оболочкой для запуска Perl. Нужно ли было писать сценарий запуска на sh? Нет, но это улучшило ремонтопригодность для администратора. И сценарий инициализации не сделал ничего более сложного, чем такие вещи, как daemon --start или daemon --stop. Если вы это сделаете, то обычные пользователи смогут запустить ваш инструмент в непривилегированном режиме, если это имеет смысл в контексте вашей программы. И им не нужно было бы иметь всевозможные сложные настройки для тонкости.
Современные дистрибутивы Linux, даже те, которые все еще используют init.d, имеют большой набор встроенных функций, упрощающих управление демонами. Графические процессы загрузки обычно используют эти функции, чтобы поддерживать красивый логотип, если только один из сценариев запуска не начинает выдавать ошибки. Ваш код Python (или любой другой язык) может не работать с этими схемами.
Если вас не волнует эстетика или ремонтопригодность, ваш сценарий инициализации можно написать так, как вы хотите. Я видел множество администраторов, которые даже не могут правильно вырезать и вставить, полностью игнорируют аргументы командной строки и просто запускают демон. Нет выключения, статуса или перезапуска. Он был незрелым, но их код все еще работал.
Я говорю между пунктами 1-2. LSB направляет вас таким образом ... и от Sys-Admin (не роль разработчика) задание требует знания sh / bash, НЕ уровня разработки (или даже легкого понимания) Python, PHP или Perl. Это для стека LAMP, а не для системных сценариев инициализации.