Qual é a diferença entre start-stop-daemon e execução com &?


18

Estou configurando um serviço no /etc/init.d. Eu estou olhando para vários scripts lá, alguns são implementados com start-stop-daemon ...e outros com /path/to/script &.

Todos eles salvam o pid em um arquivo e fazem algumas verificações.

Qual é a melhor prática, quais são as diferenças, o que é importante saber aqui ...? (em geral)

No meu caso particular, eu tenho um servidor http localhost simples e leve em java, que um aplicativo chama uma vez a cada hora mais ou menos e fornece apenas um número aleatório estúpido (sem mais detalhes aqui, apenas quero dizer que ele não usa o sistema de arquivos ou tópicos ou qualquer coisa complicada no caso de este assunto na minha pergunta)

obrigado

Respostas:


27

Um trabalho em segundo plano (ou seja, iniciado com &) ainda tem stdin, stdout e stderr conectados ao terminal em que foi iniciado. Ele pode repentinamente gravar (por exemplo, mensagens de erro) no terminal ("perturbando" o trabalho no primeiro plano) ou pausar a espera da entrada do teclado (primeiro você deve colocá-lo em primeiro plano). Obviamente, você pode redirecionar stdout e stderr para um arquivo ou para / dev / null para impedir que o trabalho em segundo plano seja gravado no terminal.

Um trabalho em segundo plano também pode ser colocado em primeiro plano - por exemplo, o trabalho em primeiro plano atual é parado e o fgcomando (primeiro plano) é usado para colocar um trabalho em segundo plano em primeiro plano. Um trabalho em segundo plano também pode ser alcançado por sinais do terminal - por exemplo. Suspenda quando você fechar o terminal, que geralmente termina (a maioria) dos programas iniciados no terminal.

Um daemon - como o iniciado automaticamente pelo init.d, mas que também pode ser iniciado manualmente a partir de um terminal - por outro lado, é executado desconectado de qualquer terminal. Mesmo que tenha sido iniciado manualmente a partir de um terminal, um daemon será desconectado do terminal, para que ele não possa gravá-lo (stdout, stderr) nem lê-lo (stdin). Também é "imune" aos sinais enviados "automaticamente" pelo terminal. (embora você possa enviar sinais usando kill -signal pid).

"Segundo plano" e "primeiro plano" se referem ao status do processo em algum terminal - seja o processo que está controlando o terminal atualmente ou não. Uma vez que os daemons não estão conectados a um terminal (mas foram desconectados em todos os aspectos), não é possível dizer que ele esteja sendo executado em segundo plano. Os daemons são apenas processos em execução sem serem associados a um terminal - nem em primeiro plano nem em segundo plano.

Se você usar psas opções que mostram qual terminal um processo usa, verá que os empregos anteriores e de segundo plano são associados a um terminal (por exemplo, tty2). Daemons, por outro lado, tem um "?" nesta área.

Os daemons geralmente se comportam como tal, mesmo que sejam iniciados manualmente. Criar um daemon de sua autoria é bastante trabalhoso - existem alguns truques envolvidos para desconectá-lo totalmente do terminal. Você deve criar seu próprio usuário / grupo para executar como. Você geralmente deve usar / tmp, / var / tmp ou / var / run se quiser criar arquivos - geralmente não deve ter direitos em nenhum outro lugar. Como não pode relatar erros em um terminal, você deve escrevê-lo em um arquivo de log (por exemplo, é o seu próprio arquivo de log em / var / log). Os daemons devem fazer uma entrada em / var / run com seu PID atual e devem verificar se outra instância já está em execução. Ele deve respeitar bloqueios (/ var / lock) para arquivos ou dispositivos, quando aplicável. Ele deve responder ao SIGHUP recarregando seus arquivos de configuração e usar configurações atualizadas.

Outro ponto é como a maioria dos daemons funciona. Um daemon é geralmente um único executável que pode ser executado em um de dois modos distintos; dependendo se é o daemon original - o pai - iniciado na inicialização ou manualmente ... ou um filho gerado por esse pai. O processo pai geralmente fica parado e aguarda algum evento - um tempo específico, o tempo passou, uma tentativa de conectar-se a uma porta de rede específica ou o que for. Quando isso acontece, o pai cria um processo filho idêntico a si mesmo (usando a chamada de sistema fork ()) - e imediatamente volta a aguardar outro evento (e talvez gerar mais filhos). É o processo filho que realmente fará o trabalho - como sincronizar um disco, executar um comando (por exemplo cron) ou estabelecer uma conexão de rede (por exemplo, sshdouftpd) A única diferença entre pai e filho é que eles têm PIDs diferentes e que o PPID (pai-PID) da criança é o PID do processo pai - isso pode ser usado para determinar se o processo é pai ou filho. Portanto, o mesmo processo deve ser capaz de operar em dois modos - como o pai que está esperando (e o que gera) ou como um filho que trabalha.

Embora não seja difícil escrever um daemon, também não é trivial - como você vê, existem alguns "truques" que você deve conhecer primeiro. Em geral, eu acho que escrever um daemon exigiria muito esforço para pouquíssimo ganho em comparação com outras alternativas:

Usar nohupou disownem um trabalho em segundo plano geralmente é uma alternativa suficientemente boa, pois mantém o processo ativo, mesmo que o terminal seja fechado. Geralmente, é uma boa idéia redirecionar stdout e stderr para um arquivo ou para / dev / null. Para programas mais interativos, screené uma boa maneira de deixar algo "de lado" até que você precise. at, batche crontabtambém vale a pena considerar.


11
Também me lembro dos meus antigos cursos de sistema unix, que quando iniciado a partir de um terminal, o servidor também deve deixar seu [grupo de processos] [ en.wikipedia.org/wiki/Process_group] . Até onde eu lembro. Para que o processo seja imune a qualquer sinal do seu terminal original.
yves Baumes
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.