• # double fork

    Posté par . En réponse à la dépêche Évolutions techniques de systemd. Évalué à 5.

    Il devrait être capable de couper complètement un service. Cela semble facile mais est en réalité très difficile. Sous UNIX, un processus qui fait un double fork (le programme se relance lui‐même en tâche de fond) sort complètement de la supervision du processus qui l’a lancé. Prenons par exemple un script CGI lancé par un serveur Web. Lorsqu’il fait un double fork, il devient orphelin et est rattaché au processus de PID 1. L’arrêt du serveur Web ne le concerne pas, et aucun script système n’est en mesure de le retrouver automatiquement pour le couper.

    Ce n'est pas tout-à-fait exact :

    un processus devient orphelin lorsque son père se termine (il est alors adopté par init).

    Si un processus A fait un "double-fork", entendez par là qu'il fait un fils B puis B fait un petit-fils C, alors C n'est pas orphelin tant que B n'est pas mort ; ça n'a rien à voir avec le fait de faire un double fork.

    En pratique, les démons font souvent un fork pour changer de PID et se détacher du terminal ; puis ils font des fils spécilisés sur des traitements et des connexions. Ces fils sont donc des petits-fils du démon initial, mais ils ne sont pas orphelins puisque le démon forké est vivant ! Mais avec un PID différent du PID initial.

    Comme tout ceci est difficile à suivre (pas tant que ça grâce à pstree), la notion de groupe de processus peut simplifier certaines opérations, en effet.