But de fork() puis setsid() et re-fork() ?

Le
Manuel Pégourié-Gonnard
Bonjour,

Je viens regarder le module Perl Proc::Daemon, et il y a un truc qui
m'échappe dans la logique de la chose. Je rappelle cette logique, telle
qu'indiquée dans la documentation :

1. Forks a child and exits the parent process.
2. Becomes a session leader (which detaches the program from the
controlling terminal).
3. Forks another child process and exits first child. This prevents the
potential of acquiring a controlling terminal.
4. Changes the current working directory to "/".
5. Clears the file creation mask.
6. Closes all open file descriptors.

Ce qui m'échappe, c'est le sens de l'étape 3. Je ne comprends pas
pourquoi un setsid() ne suffit pas, et qu'il faut re-forker après.

Merci d'avance pour vos explications.

--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Nicolas George
Le #20633321
Manuel Pégourié-Gonnard wrote in message
3. Forks another child process and exits first child. This prevents the
potential of acquiring a controlling terminal.



Ce qui m'échappe, c'est le sens de l'étape 3. Je ne comprends pas
pourquoi un setsid() ne suffit pas, et qu'il faut re-forker après.



Si un processus qui est session leader n'a pas de tty de contrôle et en
ouvre un sans l'option O_NOCTTY, alors il se retrouve attaché à ce tty.
Pour éviter ça, l'étape 3 élimine la condition « qui est session leader ».
C'est doublement naze, comme méthode : d'une part parce que ça correspond à
une API mal conçue (un appel système dédié pour s'attacher à un fd, ou à la
rigueur un ioctl, serait infiniment préférable) et d'autre part parce que
c'est de la programmation défensive (si on ne veut pas acquérir de tty de
contrôle, on utilise O_NOCTTY).
Publicité
Poster une réponse
Anonyme