O ID do processo e o id da sessão de um daemon podem ser diferentes?

Question

Tanto quanto eu entendi de artigos diferentes e aqui , um daemon possui os seguintes recursos:

1. O ID do processo pai deve ser 1.
2. Nenhum terminal deve ser associado ao processo.
3. O ID do processo, o ID da sessão e o ID do grupo de processos devem ser iguais.

Parece funcionar para alguns dos daemons do meu sistema. No entanto, o avahi-daemon do meu sistema está tendo o PID 678 e os outros dois ids, 677. Por que é isso?

Existem alguns outros recursos também para identificar daemons?

    

Answer 1

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.

1. O daemon gera um processo filho.
2. O daemon sai do seu processo "principal" / pai.
3. 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.

Answer 2

Isso significa apenas que o pai do daemon (pid 677) iniciou a nova sessão, bifurcou-se, e o filho (pid 678) herdou essa sessão e continuou executando.

Isso poderia acontecer se algum script wrapper fosse usado para daemonizar alguma coisa (e, por algum motivo, não executasse seu alvo - talvez para manipular reinicializações) ou apenas porque o processo optou por bifurcar novamente antes de entrar em seu estado estacionário. / p>

Eu diria que um processo é efetivamente um daemon se o PPID for 1 e não tiver terminal de controle. A restrição id do ID do grupo / processo também é verdadeira, mas na verdade não é necessária para o comportamento demoníaco.