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