Como o DAEMON (3) funciona? Executar como processo em segundo plano

Question

Quais são os passos para fazer o processo se destacar do terminal? Para isso achei man page de daemon() Na descrição, eles mencionaram

If nochdir is zero, daemon() changes the process's current working directory to the root directory ("/"); otherwise, the current working directory is left unchanged.

If noclose is zero, daemon() redirects standard input, standard output and standard error to /dev/null; otherwise, no changes are made to these file descriptors.

Na verdade, eu estava tentando fazer meu código python rodar como daemon. Eu encontrei o tcollector code aqui . Nesse código, eles também estão seguindo as mesmas etapas, como na descrição de daemon() . Então, a minha pergunta é, por que devemos fazer essas etapas (wrt daemonize() em tcollector ) como

por que alterar dir para / , umask para 022 e depois chamar os.setsid() , etc.

    

Answer 1

Na verdade, há mais do que você citou, mas acho que a página de manual pode ser mais clara.

If nochdir is zero, daemon() changes the process's current working directory to the root directory (/)

A suposição aqui é que o programa é iniciado a partir de uma linha de comando de administradores, e a idéia é desassociar o daemon do que o administrador estava fazendo no momento. Alterar o diretório de trabalho para / impede que o daemon mantenha um ponto de montagem ocupado. Por exemplo. se o diretório de trabalho fosse /home/admin e algum tempo depois você quisesse desmontar /home , o daemon evitaria isso.

If noclose is zero, daemon() redirects standard input, standard output and standard error to /dev/null;

Isso evita que o daemon confunda os usuários escrevendo mensagens de erro dispersas ou algo semelhante em seu terminal. O que o daemon provavelmente deveria fazer, é abrir algum arquivo de log (configurado), e escrever lá o que quer que ele se comunique com o exterior.

(This function forks, and if the fork(2) succeeds, the parent calls _exit(2), so that further errors are seen by the child only.)

Mais uma vez, para desassociar da sessão de shell do administrador, o programa principal retorna imediatamente, e a outra parte fica em segundo plano, portanto não é necessário solicitar explicitamente que o programa seja iniciado em segundo plano (por exemplo, ./daemon & )

Agora, o que a página de manual não diz explicitamente, mas implica aqui (em BUGS):

The GNU C library implementation of this function was taken from BSD, and does not employ the double-fork technique (i.e., fork(2), setsid(2), fork(2)) that is necessary to ensure that the resulting daemon process is not a session leader. Instead, the resulting daemon is a session leader.

daemon() também chama setsid() para se liberar da sessão < href="http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_115"> controle do terminal e, portanto, dos sinais enviados pelo terminal. Mas, como diz a citação, isso deixa a possibilidade de que, se abrir um dispositivo terminal, pode, acidentalmente, conseguir isso como um terminal de controle. Para evitar isso, alguns programas chamam fork() , então setsid() do filho e, em seguida, bifurcam novamente, saindo de ambos os pais para que o processo resultante não seja um líder de sessão (o do meio é / era) e não pode obter um terminal de controle. O programa em Python que você se refere faz exatamente isso.

Alterar o umask parece não estar relacionado à daemonização. Talvez esse programa tenha uma necessidade particular.