init.d scripts escritos em Python

9

Uma pergunta surgiu no StackOverflow perguntando sobre como escrever init.d de scripts em Python. Um comentário indicou que esses scripts devem ser programados em shell e não em Python. Está escrevendo scripts init.d no Python:

  1. Ruim. Mau. Mau. Nunca faça isso.
  2. Não é uma prática recomendada.
  3. OK, com ressalvas.
  4. Dogma legado.
  5. Totalmente bem.

Seria ótimo conhecer alguns cenários de pesadelo, ou se essa regra for escrita no sangue de alguns sysadmins.

    
por mjhm 10.11.2010 / 18:29

4 respostas

8

Eu diria # 2, mas muito próximo do # 1 - "Bad. Bad. Bad. Nunca faça isso." O padrão, como é, para scripts de inicialização do Linux, é o LSB , e embora nunca saia e diga que "estes são roteiros de shell de bourne", várias suposições são feitas. Primeiro, as linhas que começam com # são comentários, funcionam bem. Mais problemático é o requisito de que o script de inicialização execute os comandos de /lib/lsb/init-functions "no ambiente atual (consulte ponto de comando interno especial do shell)".

Mas o mais importante, se você está fazendo algo realmente complicado aqui, você está fazendo errado. Os scripts de inicialização devem ser muito simples e utilitários. Eles devem ser scripts no sentido clássico, não em programas. É melhor sugá-lo e fazer um script de shell simples que qualquer sysadmin pode facilmente criar uma aparência rápida do que fazer algo bonito e projetado em Python.

Outra consideração a ter em conta é systemd , que pode ou não ser o futuro de todos Inicialização do Sistema No Linux. Sob systemd, a inicialização é feita por arquivos de configuração simples, em vez de scripts, a idéia é que toda a inicialização se encaixa em vários padrões de design padrão e realmente você deve apenas escolher um. Se você programa usa algo complicado para inicialização, isso deve ser feito fora do próprio script de inicialização.

    
por 10.11.2010 / 20:29
10

Eu não vejo um problema com isso, se você sabe, com certeza, que o interpretador Python estará disponível quando o script init.d estiver sendo executado. Isso, para mim, indica que você está olhando para 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 sua sequência de inicialização e isso é mais uma coisa que você precisa verificar nas atualizações.

Eu acho que isso significa que eu estou dizendo "3. OK, com advertências".

    
por 10.11.2010 / 18:46
2

Concordo com "3. OK, com ressalvas", mas por diferentes razões. Minha experiência no Solaris foi que eles tinham uma cópia do sistema operacional Perl para alguns de seus programas internos. O shell script 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 do administrador. E o script de inicialização não fez nada mais complicado que coisas como daemon --start ou daemon --stop . Se você fez isso, usuários regulares podem iniciar sua ferramenta no modo não privilegiado, se isso fizer sentido no contexto do seu programa. E eles não precisariam ter todos os tipos de configurações complicadas para finesse.

As distribuições Linux modernas, mesmo aquelas que ainda usam init.d , possuem uma grande coleção de funções pré-criadas para facilitar o gerenciamento de daemons. Os processos de inicialização gráfica utilizam rotineiramente essas funções para manter o logotipo bonito, a menos que um dos scripts de inicialização comece a emitir 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 de inicialização pode ser escrito da maneira que você quiser. Eu vi muitos administradores, que não podem nem mesmo cortar e colar corretamente, ignorar completamente os argumentos da linha de comando e eles apenas iniciam o daemon. Nenhum desligamento, status ou reinicialização. Era imaturo, mas o código deles ainda era executado.

    
por 10.11.2010 / 19:27
1

Eu digo entre # 1-2. O LSB direciona você dessa maneira ... e de um Sys-Admin (função não-dev), o job req dita sh / bash knowledge, NÃO dev-level (ou até mesmo leve entendimento) de python, PHP ou perl. Isso é para a pilha LAMP, não para os scripts init do sistema.

    
por 08.02.2013 / 16:50