Je suis en train de transformer un programme non interactif (mais
tournant dans un terminal) en daemon. Pour l'instant, je lance le truc
par un 'nohup mon_programme &', mais ce n'est pas satisfaisant pour
plusieurs raisons que je n'évoquerai pas ici (il y a au moins un
problème de redirection des flux parce que le truc utilise stderr et
stdout, des fflush() et nohup n'aime vraiment pas...).
J'aimerais pouvoir lancer directement le truc et qu'il passe en
tâche de fond. J'ai commencé par rajouter un bout de code rendant le
programme insensible au signal SIGHUP. Je n'ai par contre rien trouvé
pour détacher le programme comme le fait '&' dans un shell. Je suppose
que ça doit être trivial, mais je ne dois pas chercher au bon endroit.
Merci de vos lumières,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Selon les sources, l'une ou l'autre stratégie sera préférée, et les deux sont souvent citées dans les docs. Je pense que c'est une question de goût et d'habitude, sachant que si l'on convertit un programme complexe en daemon, il peut rester des appels aux E/S standards non supprimés et que c'est plus propre de les envoyer sur /dev/null que de les fermer complètement.
Un point à considérer, c'est : le démon doit-il lancer des enfants après avoir mis en place de la tuyauteries. Si c'est le cas, il a tout intérêt à avoir un /dev/null sur 0, 1 et 2, parce que ça lui garantit qu'un fd retourné par pipe ne peut pas être 0, 1 ou 2, et du coup rend infiniment plus facile les manipulations à base de dup2.
Damien Wyart wrote in message <494644b3$0$22510$426a74cc@news.free.fr>:
Selon les sources, l'une ou l'autre stratégie sera préférée, et les deux
sont souvent citées dans les docs. Je pense que c'est une question de
goût et d'habitude, sachant que si l'on convertit un programme complexe
en daemon, il peut rester des appels aux E/S standards non supprimés et
que c'est plus propre de les envoyer sur /dev/null que de les fermer
complètement.
Un point à considérer, c'est : le démon doit-il lancer des enfants après
avoir mis en place de la tuyauteries. Si c'est le cas, il a tout intérêt à
avoir un /dev/null sur 0, 1 et 2, parce que ça lui garantit qu'un fd
retourné par pipe ne peut pas être 0, 1 ou 2, et du coup rend infiniment
plus facile les manipulations à base de dup2.
Selon les sources, l'une ou l'autre stratégie sera préférée, et les deux sont souvent citées dans les docs. Je pense que c'est une question de goût et d'habitude, sachant que si l'on convertit un programme complexe en daemon, il peut rester des appels aux E/S standards non supprimés et que c'est plus propre de les envoyer sur /dev/null que de les fermer complètement.
Un point à considérer, c'est : le démon doit-il lancer des enfants après avoir mis en place de la tuyauteries. Si c'est le cas, il a tout intérêt à avoir un /dev/null sur 0, 1 et 2, parce que ça lui garantit qu'un fd retourné par pipe ne peut pas être 0, 1 ou 2, et du coup rend infiniment plus facile les manipulations à base de dup2.
Grasshoper
Dans <unistd.h>, sous Unix, on trouve une fonction daemon(..) qui sert à ça. Je n'en connais pas la portabilité. man 3 daemon.
Dans <unistd.h>, sous Unix, on trouve une fonction daemon(..) qui sert à
ça. Je n'en connais pas la portabilité. man 3 daemon.
