Surgiu uma pergunta no StackOverflow perguntando sobre como escrever init.dscripts em Python. Um comentário indicou que esses scripts devem ser programados em shell, não em Python. Está escrevendo init.dscripts em Python:
Seria ótimo conhecer todos os cenários de pesadelo ou se essa regra está escrita no sangue de alguns administradores de sistemas.
Respostas:
Eu diria que # 2, mas muito perto do # 1 - "Mau. Mau. Mau. Nunca faça isso." O padrão, como é, para scripts de inicialização do Linux está no LSB e, embora nunca saia e diga "esses são scripts de bourne shell", várias suposições são feitas. Um, que as linhas que começam com # são comentários, funciona bem. Mais problemático é o requisito de que o script init execute os comandos /lib/lsb/init-functions"no ambiente atual (consulte o ponto de comando interno especial do shell)".
Mas o mais importante, se você está fazendo algo realmente complicado aqui, está fazendo errado. Os scripts init devem ser muito simples e utilitários. Eles devem ser scripts no sentido clássico, não programas. É melhor absorver e criar um script de shell simples para que qualquer administrador de sistemas possa facilmente criar um olhar rápido do que criar algo bonito e projetado em Python.
Outra consideração a ter em mente é systemd: o que pode ou não ser o futuro de toda a inicialização do sistema no Linux. No systemd, a inicialização é feita por arquivos de configuração simples, e não por scripts, com a idéia de que toda a inicialização se encaixa em vários padrões de design padrão e, na verdade, você deve escolher apenas um. Se o seu programa usa algo complicado para a inicialização, isso deve sair do próprio script init.
Não vejo problema nisso, se você souber, com certeza, que o interpretador Python estará disponível quando o script init.d estiver sendo executado. Isso, para mim, indica que você está vendo algo sendo feito relativamente tarde em um nível de execução multiusuário (ou "console gráfico").
No entanto ... Isso significa que uma versão específica do interpretador Python PODE ser vital para a sua sequência de inicialização e essa é mais uma coisa que você precisa verificar nas atualizações.
Acho que isso significa que estou dizendo "3. OK, com ressalvas".
Eu concordo com "3. OK, com ressalvas", mas por razões diferentes. Minha experiência no Solaris foi que eles tinham uma cópia do Perl no SO para alguns de seus programas internos. O script do shell nada mais era do que o shell para fazer o Perl começar. O script de inicialização teve que ser escrito em sh? Não, mas melhorou a capacidade de manutenção para o administrador. E o script init não fez nada mais complicado que coisas como daemon --startou daemon --stop. Se você fez isso, usuários comuns podem iniciar sua ferramenta no modo sem privilégios, se isso fizer sentido no contexto do seu programa. E eles não precisariam ter todos os tipos de configurações complicadas para refinar.
As distribuições modernas do Linux, mesmo as que ainda estão em uso init.d, têm uma grande coleção de funções pré-criadas, destinadas a facilitar o gerenciamento de daemons. Os processos de inicialização gráfica rotineiramente utilizam essas funções para manter o logotipo bonito, a menos que um dos scripts de inicialização comece a exibir erros. Seu código Python (ou qualquer outro idioma) pode não funcionar bem com esses esquemas.
Se você não se importa com estética ou manutenção, seu script init pode ser escrito da maneira que você quiser. Eu já vi muitos administradores, que não conseguem nem recortar e colar corretamente, ignoram completamente os argumentos da linha de comando e eles apenas iniciam o daemon. Sem desligamento, status ou reinicialização. Era imaturo, mas o código deles ainda funcionava.
Eu digo entre # 1-2. O LSB o direciona dessa maneira .. e a partir de um administrador de sistema (função não dev), o req da tarefa determina o conhecimento sh / bash, NÃO o nível dev (ou mesmo o entendimento leve) de python, PHP ou perl. Isso é para a pilha LAMP, não para os scripts de inicialização do sistema.