Strictement parlant, la double fourche n'a rien à voir avec le fait de re-parenter le démon en tant qu'enfant de init . Pour que l'enfant redevienne parent, il suffit que le parent se retire. Cela peut être fait avec une seule fourche. De même, une double fourche ne permet pas de re-parenter le processus démon à init ; le parent du démon debe sortie. En d'autres termes, le parent quitte toujours le processus lorsqu'il prend la forme d'un démon approprié, de sorte que le processus démon est de nouveau apparenté à init .
Pourquoi cette double fourchette ? POSIX.1-2008 Section 11.1.3, " Le terminal de contrôle "La réponse se trouve dans l'encadré (c'est nous qui soulignons) :
Le terminal de contrôle d'une session est allouée par le chef de session d'une manière définie par la mise en œuvre. Si un chef de session n'a pas de terminal de contrôle et qu'il ouvre un fichier de terminal qui n'est pas déjà associé à une session sans utiliser l'option O_NOCTTY (voir open() ), la question de savoir si le terminal devient le terminal de contrôle du chef de session est définie au niveau de l'implémentation. Si un processus qui est n'est pas un animateur de session ouvre un fichier terminal, ou la touche O_NOCTTY L'option est utilisée sur open() , ce terminal ne devient pas le terminal de contrôle du processus appelant .
Cela nous indique que si un processus démon fait quelque chose comme ceci ...
int fd = open("/dev/console", O_RDWR);
... puis le processus démon pourrait acquérir /dev/console comme terminal de contrôle, selon que le processus démon est un chef de session ou non, et selon l'implémentation du système. Le programme peut garantie que l'appel ci-dessus n'acquiert pas de terminal de contrôle si le programme s'assure d'abord qu'il ne s'agit pas d'un chef de session.
Normalement, lors du lancement d'un démon, setsid est appelé (par le processus enfant après avoir appelé fork ) pour dissocier le démon de son terminal de contrôle. Cependant, l'appel à setsid signifie également que le processus appelant sera le chef de session de la nouvelle session, ce qui laisse ouverte la possibilité que le démon récupère un terminal de contrôle. La technique de la double fourche permet de s'assurer que le processus démon n'est pas le chef de session, ce qui garantit qu'un appel à open comme dans l'exemple ci-dessus, ne permettra pas au processus démon d'obtenir à nouveau un terminal de contrôle.
La technique de la double fourchette est un peu paranoïaque. Elle n'est peut-être pas nécessaire si vous savoir que le démon n'ouvrira jamais un fichier de périphérique de terminal. De plus, sur certains systèmes, il peut ne pas être nécessaire de le faire même si le démon ouvre un fichier de terminal, puisque ce comportement est défini par l'implémentation. Cependant, une chose qui n'est pas définie au niveau de 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 un 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, la technique de la double fourchette est essentielle.
1 votes
stackoverflow.com/questions/10932592/why-fork-twice/
4 votes
L'une des difficultés de la double fourche est que le parent ne peut pas facilement obtenir le PID du processus petit-enfant (la balise
fork()renvoie le PID de l'enfant au parent, il est donc facile d'obtenir le PID du processus enfant, mais pas si facile d'obtenir le PID du processus petit-enfant ).