Um daemon bem comportado deve se auto-sincronizar? [fechadas]

Question

Em esta resposta , é mencionado de passagem que não é apropriado que um processo de daemon se conserte para init com o truque do duplo garfo e saída. Os links de resposta para um site que não está mais ativo mas eu encontrei no Internet Archive . Ele lista uma série de razões para isso que se resumem a "Você não deve daemonizar porque pode quebrar init ou outras ferramentas que não esperam daemonização, e se alguém estiver executando isso interativamente, elas devem usar & ou nohup para solicitar explicitamente o plano de fundo. " Esses motivos parecem bastante convincentes, na verdade, já que um daemon configurado adequadamente já deve estar em execução em um ambiente são no momento em que recebe o controle. (Bem, idealmente, ele está sendo executado em um contêiner com muita automação sofisticada, mas isso é outra história.)

No entanto, não entendo por que temos setsid(2) se não formos usar isto. Eu posso entender setpgid(2) ; você precisa disso para implementar um shell (moderno (ish)), mas parece que a maneira somente para chamar de forma confiável o setsid(2) é para daemonizar, e a man page lhe diz para fazer isso. Suponho que você possa usá-lo para implementar várias ferramentas de baixo nível que eventualmente executam login(1) , mas setsid(2) não é uma chamada de sistema privilegiada e sua página man não faz menção a esse caso de uso. O pessoal do Python, pelo menos, parece pensar que a demonização inclui a reparação e Eu já vi essa atitude em vários outros contextos (particularmente na academia, como o livro que o PEP cita).

Como mais um ponto de referência, daemonize(1) e daemon(3) são coisas (em alguns sistemas), e a primeira página do manual diz isso:

Most programs that are designed to be run as daemons do [various things including reparenting] for themselves. However, you'll occasionally run across one that does not. When you must run a daemon program that does not properly make itself into a true Unix daemon, you can use daemonize to force it to run as a true daemon.

Qual é o comportamento correto de um daemon na inicialização e, em particular, ele deve se reparar?

    

Answer 1

Sempre achei que setsid() e líderes de sessão tinham a ver com controle de processo e como a entrega de sinal com terminais funciona. Eles são um nível acima dos grupos de processos.

Uma resposta no Stackoverflow refere-se a POSIX.1-2008 , que diz:

3.339 Session

A collection of process groups established for job control purposes. Each process group is a member of a session. A process is considered to be a member of the session of which its process group is a member. A newly created process joins the session of its creator. A process can alter its session membership; see setsid(). There can be multiple process groups in the same session.

E Capítulo 11 prossegue, informando como os sinais são fornecidos com base nos grupos de processos e terminal de controle da sessão.

Na prática, todas as "sessões" logicamente separadas no sistema Linux que eu observei, são executadas em ID de sessão separada: s, então login ou algum outro ( sshd , screen ) executa setsid como você sugeriu.

Quanto ao que um daemon deve fazer, suponho que dependa de qual sistema de init se usa. No Linux, com scripts de inicialização tradicionais do System V, o daemon precisa ir ao fundo em si (ou com a ajuda de um ajudante). Embora com o sysvinit, os scripts init podem ser executados diretamente do shell de um administrador, e isso pode não ser um ambiente limpo em todos os casos. (É possível herdar, por exemplo, limites de recursos da sessão.)

Em Upstart e Systemd, pode ser preferível que o daemon não se bifurque, já que o sistema init pode fazer isso. (E o Upstart em particular faz algumas coisas engraçadas para seguir os daemons de bifurcação.)

(Eu não sei sobre outros Unixes, mas como @Stephen Harris comentado , pode ser uma boa idéia para um programa daemon suportar tanto o comportamento de bifurcação quanto de não-bifurcação.)

Depois, há ssh-agent , que geralmente é executado por um usuário sozinho, sem suporte do sistema init. É bastante útil que ele possa ser bifurcado para o fundo (com setsid ) e permanecer ativo, então ele pode ser usado a partir de múltiplos shells. ( screen windows, xterm s ...) Ele também tem uma saída útil quando é iniciado, então executá-lo com nohup seria um pouco complicado.

    

Answer 2

Um daemon bem-comportado deve se daemonizar porque é o que é esperado de um daemon. O daemon deve funcionar de forma adequada, mesmo que não seja iniciado a partir de uma estrutura de lançamento do daemon.

Um daemon bem-comportado deve ter a opção de não se daemonizar, de modo que possa ser iniciado por um supervisor. (Os kernels recentes do Linux facilitam a supervisão dos daemons que são double-fork, mas nem todos os sistemas executam um kernel Linux recente e nem todo programa supervisor assume um kernel recente do Linux.)