Portanto, um ponto dos trabalhos iniciados é ser simples de escrever.
Há muita magia de script de shell nos scripts init.d que é repetida várias vezes. Declarações de caso, rastreamento de pidfile, linhas de comentário lsb. Não está muito claro como escrever um bom script init.d sem ter lido um.
Se você já teve o trabalho de escrever tudo isso, não precisa de um trabalho inicial, a menos que, como mencionei em outro comentário, dependa de outro trabalho / evento inicial.
Mas, realmente, o iniciante torna as coisas realmente simples. Você não deve precisar de uma pré-inicialização, a menos que precise configurar coisas como tmpdirs, ulimits ou argumentos de tempo de execução. Você não deve precisar de uma pós-parada, a menos que queira se arrumar depois de um serviço (o serviço realmente deve ser limpo após a 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 despejada em pré-inicialização. A chave é que é apenas um pequeno trecho de código para configurar o ambiente para o processo, e não a lógica de lidar com start / stop / respawn / etc.
A parte mais difícil, e a que as pessoas mais erram, é saber quando iniciar / parar seu trabalho. start on runlevel [2345]
parece lógico, mas ignora o fato de que a rede está surgindo paralelamente nesse ponto, assim como as montagens locais do sistema de arquivos. A chave é tentar descobrir exatamente as coisas mínimas que você precisa (outros serviços, sistemas de arquivos, rede, etc.) para executar e iniciar quando essas tarefas forem concluídas. A maioria dos serviços de rede tradicionais deve funcionar start on (local-filesystems and net-device-up IFACE!=lo)
.