Do init.d para o upstart, existe uma ponte?

11

Eu tenho um script perfeitamente bom para usar em /etc/init.d. Na verdade, eu tenho muitos deles, todos criados com o Wrapper de serviço Java da Tanuki.

Parece-me que poderia haver um modelo simples para envolver um script de shell como um script inicial, mas um pouco de googling não está revelando um.

Estou sentindo falta de algo?

    
por bmargulies 24.11.2010 / 23:06

3 respostas

9

Não me lembro de ver um modelo para isso. É um pouco irônico, no entanto, que tecnicamente, seu upstart que está iniciando seu script init.d em primeiro lugar graças ao trabalho de compatibilidade retroativa rc e rcS.

Eu consideraria reescrever o que você tem como um trabalho inicial, no entanto, eu sei que alguns scripts são difíceis de converter, então aqui está o que eu fiz por um tempo em alguns dos meus scripts:

description "xyz"
author "xyz"
start on runlevel 5
stop on runlevel [!5]

pre-start script
    # do my work here to start the service
end script

post-stop script
    # do work here to stop the service
end script

Agora, dependendo da natureza do serviço, se ele persiste ou se bifurca, talvez seja necessário adicionar expect fork ou task ao arquivo de trabalho.

Só para completar o pensamento, geralmente, isso é tudo para um arquivo completo de trabalho inicial. Todo o trabalho de pré-inicialização é feito, toda a limpeza é feita, a única coisa que resta é o próprio serviço, que geralmente é adicionado com:

exec service_cmd
    
por KFro 25.11.2010 / 00:42
6

Portanto, um ponto dos trabalhos iniciantes é ser simples de escrever.

Há muita mágica de script de shell nos scripts init.d que é repetida várias vezes. Declarações de casos, rastreamento de arquivos pidfiles, linhas de comentário lsb. Não é muito claro como escrever um bom script init.d sem ter lido um.

Se você já se deu ao trabalho de escrever tudo isso, então você não precisa de um trabalho iniciante, a menos que, como mencionei em outro comentário, você dependa de outro trabalho / evento arriscado.

Mas, na verdade, o upstart torna as coisas realmente simples. Você não deve precisar de um pré-início a menos que precise configurar coisas como tmpdirs, ulimits ou argumentos de tempo de execução. Você não deve precisar de um pós-parada, a menos que você queira ter certeza de arrumar as coisas após um serviço (o serviço deve realmente estar se limpando depois da saída normal).

Muitas vezes, um script init.d gigante com muitas opções se resume a um trabalho inicial de 10 a 15 linhas. Os scripts init.d mais complexos podem ter a maior parte de sua lógica lançada no pré-início. A chave lá é que é apenas um pequeno trecho de código para configurar o ambiente para o processo, e não a lógica no manuseio start / stop / respawn / etc.

A parte mais difícil, e a que as pessoas erram mais frequentemente, é saber quando começar / parar o trabalho. start on runlevel [2345] parece lógico, mas ignora o fato de que a rede está surgindo em paralelo naquele ponto, assim como as montagens de sistema de arquivos locais. A chave é tentar descobrir exatamente as coisas mínimas que você precisa (outros serviços, sistemas de arquivos, rede, etc) para começar a executar, e começar quando isso for feito. A maioria dos serviços de rede tradicionais deve fazer start on (local-filesystems and net-device-up IFACE!=lo) .

    
por SpamapS 28.11.2010 / 00:28
3

Eu pensei que o Upstart mantém compatibilidade com versões anteriores com scripts de inicialização no estilo SysV em /etc/init.d . Você deve ser capaz de usar apenas seus scripts init inalterados.

    
por Ryan Thompson 25.11.2010 / 01:20

Tags