Por que nós daemonizamos processos? [fechadas]

6

Eu li e entendi como você cria um processo daemon, mas de tudo que eu li eu nunca entendi porque ele precisa ser feito.

Eu li que fazemos o fork - setsid - fork para evitar que o processo ganhe controle de um terminal, mas o que isso significa? Se eu iniciar um programa em segundo plano usando & (por exemplo './script &'), o que torna a execução deste processo diferente de se eu corri normalmente um programa que se transforma em um daemon?

Isso significa simplesmente que, se eu fizer o logout, o processo em segundo plano será interrompido e o daemon continuará funcionando? Estou realmente tendo problemas para entender o controle de ganho de um terminal.

A razão pela qual isso me incomoda é que estou trabalhando em um RPi embutido em um robô e, portanto, preciso fazer com que os programas iniciem na inicialização. Atualmente eu estou apenas começando eles de rc.local com um comando como este su user -c 'python /home/user/launcher.py &' & . Eu nunca tive nenhum problema com o programa começando na inicialização (eu posso até ver o processo usando ps -e quando SSHing para o RPi), mas eu gostaria de saber se há algum risco / se é uma má prática.

    
por pLesur 05.06.2016 / 16:08

1 resposta

4

Isso é mais do que uma pergunta, cada uma pode ter respostas longas. Brevemente

  • Se eu iniciar um programa em segundo plano usando & (por exemplo './script &'), o que torna a execução deste processo diferente de se eu corresse normalmente um programa que se transforma em um daemon?

    Executando um programa em segundo plano, ele não é mais diretamente controlado pelo terminal (você não pode simplesmente ^C dele), mas ele ainda pode gravar no terminal e interferir no seu trabalho. Normalmente, um daemon se separará do terminal (além de bifurcação) e sua saída / erro será redirecionada para os arquivos.

  • Isso significa simplesmente que, se eu efetuar o logout, o processo em background parará e o daemon continuará funcionando?

    O processo de segundo plano pode ser protegido com nohup , mas, a menos que sua saída seja redirecionada, o fechamento do terminal impediria sua gravação, produzindo um erro que provavelmente o impediria.

  • Eu gostaria de saber se há algum risco / se é uma má prática.

    Além do problema de manter o controle da saída do programa (e das mensagens de erro), existe o problema de reiniciá-lo se ele morrer. Um script de serviço se encaixa na maneira como os outros serviços no sistema são projetados, fornecendo uma maneira mais / menos padrão de controlar o daemon.

por 05.06.2016 / 16:25

Tags