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/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas George
Manuel Pégourié-Gonnard wrote in message <hek6o6$lh9$:
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).
Manuel Pégourié-Gonnard wrote in message
<hek6o6$lh9$1@talisker.lacave.net>:
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).
Manuel Pégourié-Gonnard wrote in message <hek6o6$lh9$:
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).
