Por que daemonizamos processos?

Question

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

Eu li que fazemos o fork - setsid - fork para evitar o processo de obter o 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 desse processo diferente de se eu executasse normalmente um programa que se transforma em um daemon?

Isso significa simplesmente que, se eu sair, o processo em segundo plano será interrompido e o daemon continuará em execução? Estou realmente tendo problemas para entender a coisa de 'obter controle de um terminal'.

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

Answer 1

Isso é mais de 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 desse processo diferente de se eu executasse normalmente um programa que se transforma em um daemon?

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

• Isso significa simplesmente que, se eu sair, o processo em segundo plano será interrompido e o daemon continuará em execução?

  O processo em segundo plano poderia ser protegido, nohupmas a menos que sua saída fosse redirecionada, fechar o terminal impediria a gravação, produzindo um erro que provavelmente o interromperia.

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

  Além do problema de acompanhar a saída do programa (e das mensagens de erro), há o problema de reiniciá-lo caso ele morra. Um script de serviço se adapta à forma como os outros serviços do sistema são projetados, fornecendo uma maneira mais/menos padrão de controlar o daemon.