Strictement parlant, le double fork n'a rien à voir avec la re-parentalité du démon en tant qu'enfant de init. Tout ce qui est nécessaire pour re-parent l'enfant est que le parent doit quitter. Cela peut être fait avec une seule fourchette. De plus, faire un double fork en lui-même ne renvoie pas le processus démon à init; le parent du démon doit quitter. En d'autres termes, le parent se ferme toujours lors de la création d'un démon approprié pour que le processus démon soit re-parenté init.
Alors pourquoi la double fourchette? POSIX.1-2008 Section 11.1.3, « Le terminal de contrôle », a la réponse (italiques ajoutés):
Le terminal de contrôle pour une session est alloué par le chef de session d'une manière définie par l' implémentation. Si un responsable de session n'a pas de terminal de contrôle et ouvre un fichier de périphérique de terminal qui n'est pas déjà associé à une session sans utiliser l' O_NOCTTYoption (voir open()), il est défini par l'implémentation si le terminal devient le terminal de contrôle du leader de session. Si un processus qui n'est pas un chef de session ouvre un fichier de terminal, ou si l' O_NOCTTYoption est activée open(), ce terminal ne doit pas devenir le terminal de contrôle du processus appelant .
Cela nous indique que si un processus démon fait quelque chose comme ça ...
int fd = open("/dev/console", O_RDWR);
... alors le processus démon peut devenir /dev/consoleson terminal de contrôle, selon que le processus démon est un chef de session et selon l'implémentation du système. Le programme peut garantir que l'appel ci-dessus n'acquiert pas un terminal de contrôle si le programme s'assure d'abord qu'il n'est pas un chef de session.
Normalement, lors du lancement d'un démon, il setsidest appelé (depuis le processus enfant après l'appel fork) pour dissocier le démon de son terminal de contrôle. Cependant, appeler setsidsignifie également que le processus appelant sera le chef de session de la nouvelle session, ce qui laisse ouverte la possibilité que le démon puisse réacquérir un terminal de contrôle. La technique du double fork garantit que le processus démon n'est pas le leader de la session, ce qui garantit alors qu'un appel à open, comme dans l'exemple ci-dessus, n'entraînera pas la réacquisition par le processus démon d'un terminal de contrôle.
La technique du double fourchette est un peu paranoïaque. Cela peut ne pas être nécessaire si vous savez que le démon n'ouvrira jamais un fichier de périphérique terminal. De plus, sur certains systèmes, cela peut ne pas être nécessaire même si le démon ouvre un fichier de périphérique terminal, car ce comportement est défini par l'implémentation. Cependant, une chose qui n'est pas définie par l'implémentation est que seul un chef de session peut allouer le terminal de contrôle. Si un processus n'est pas un chef de session, il ne peut pas allouer de terminal de contrôle. Par conséquent, si vous voulez être paranoïaque et être certain que le processus démon ne peut pas acquérir par inadvertance un terminal de contrôle, quelles que soient les spécificités définies par l'implémentation, alors la technique du double fork est essentielle.