No UNIX, quando um processo pai desaparece, pensei que todos os processos filhos redefinissem o init como pai. Isso não está correto o tempo todo? Há alguma exceção?
Movendo meu comentário para uma resposta ... Não acredito que haja exceções.
Descobri que "às vezes o processo pai é eliminado antes de seu filho ser morto. Nesse caso, o" pai de todos os processos ", init process, se torna o novo PPID (ID do processo pai). Às vezes, esses processos são chamados processo órfão ". fonte
Três respostas escritas em 2014, todas dizendo que no Unices e no Linux o processo é reparado para processar # 1 sem exceção. Três respostas erradas. ☺
Como o SUS diz, citado em uma das outras respostas aqui, então não vou citar novamente, O processo pai de filhos órfãos é configurado para um processo definido pela implementação . Cristian Ciupitu está certo em consultar a documentação do Linux para ver o que a implementação define. Mas ele está sendo enganado por essa documentação, que é inconsistente e não está atualizada.
Dois anos antes de essas três respostas serem escritas, e chegando rápido até três anos atrás, no momento em que escrevi a primeira resposta, o kernel do Linux mudou. Os desenvolvedores do systemd adicionaram a capacidade de os processos se configurarem como "sub-níveis". A partir do Linux 3.4, os processos podem emitir a chamada de sistema prctl() com a opção PR_SET_CHILD_SUBREAPER e, como resultado, eles, e não o processo # 1, se tornarão pais de qualquer um de seus processos descendente órfãos. A página man de prctl() está atualizada, mas outras man pages não foram atualizadas e feitas consistentes.
Na versão 10.2, o FreeBSD ganhou a mesma capacidade, estendendo sua chamada de sistema procctl() com as opções PROC_REAP_ACQUIRE e PROC_REAP_RELEASE . Adotou este mecanismo do FreeBSD DragonFly; que ganhou na versão 4.2, originalmente chamada reapctl() mas renomeada durante o desenvolvimento para procctl() .
service-manager - já fazem uso disso.
Se esse supervisor de daemon não for o processo # 1 e gerar um serviço como uma sessão de login interativa, e nessa sessão será feito um the (bastante equivocado) truque de tentar "daemonizar" em dobro- fork() , então o processo vai acabar como filho do supervisor daemon, não do processo # 1. Esperar ser capaz de gerar daemons diretamente nas sessões de login é um erro fundamental, é claro. Mas essa é outra resposta.
procctl() . Páginas de manual do DragonFly BSD. § 2. De acordo com a exit página man do The Single UNIX® Specification, Versão 2 :
The parent process ID of all of the calling process' existing child processes and zombie processes is set to the process ID of an implementation-dependent system process. That is, these processes are inherited by a special system process.
Para a maioria das variantes do Unix, esse processo especial é init (PID 1).
A página man do wait(2) do Linux confirma isso:
If a parent process terminates, then its "zombie" children (if any) are adopted by init(8), which automatically performs a wait to remove the zombies.
O FreeBSD wait(2) , o NetBSD wait(2) , OpenBSD wait(2) e Mac OS X wait(2) confirmam isso também:
If a parent process terminates without waiting for all of its child processes to terminate, the remaining child processes are assigned the parent process 1 ID (the init process ID).
A página do manual do Oracle Solaris 11.1 wait(3C) também confirma isso:
If a parent process terminates without waiting for its child processes to terminate, the parent process ID of each child process is set to 1, with the initialization process inheriting the child processes; see
Intro(2).
Eu não acredito nisso. Ele sempre vai para o processo init.