Suas características são muito restritivas. A noção chave aqui é: um daemon é um processo em segundo plano, portanto não pode ser o processo de controle de um terminal, nem pode ter um terminal de controle . Esta simples "regra" permite que os daemons sobrevivam através de terminais abertos / fechados e login / logout de usuários.
Cada terminal possui uma sessão de controle, ou seja, um conjunto de processos que foram gerados por esse terminal. O líder da sessão, geralmente um shell, é o processo de controle do terminal. Dizem que o terminal é o terminal de controle do shell.
Como você poderá ler em esta resposta a uma das minhas perguntas , quando um terminal estiver fechado, ele envia um sinal SIGHUP
para seu processo de controle, o shell. Isso geralmente faz com que todo o processo anexado a este shell morra, pois o shell retransmitirá o SIGHUP
que recebeu para todos os seus trabalhos.
Os processos do daemon must escapam dessa cadeia, pois devem sobreviver aos logins e logouts dos usuários. Por esta razão, eles têm que se separar da sua shell pai. Uma maneira comum de fazer isso é dobrar o garfo.
- O daemon gera um processo filho.
- O daemon sai do seu processo "principal" / pai.
- Todo o trabalho é feito na criança.
Como as shells não mantêm as pegadas dos netos, elas não enviam SIGHUP
para a parte restante do daemon. Agora, nesta configuração, os netos (daemon) devem basicamente ter:
- Seu próprio PID, como qualquer outro processo.
- O PGID de seu pai agora terminado.
- O PPID do subpertutor mais próximo, geralmente PID 1.
- O SID de seu pai agora terminado, que geralmente é o SID do shell também.
Note que matar o pai não era particularmente necessário: o processo teria morrido com o seu terminal. No entanto, para evitar processos inúteis, é um pouco mais limpo encerrar o pai imediatamente, antes que a criança comece a trabalhar.
Nesta situação, o processo pode ser chamado de daemon. Fechar o terminal não vai matá-lo. No entanto, é muito comum dar uma nova sessão aos processos daemon. No nível da API, isso é feito usando a chamada do sistema setsid
. Depois de usado, o processo deve ter:
- Um PID inalterado.
- Um PPID inalterado (subpergente mais próximo).
- Um novo SID, geralmente o mesmo que seu PID.
- Um novo GID, pois os processos do mesmo grupo também devem estar na mesma sessão.