Pourquoi le parent devrait mourir, en train de créer un démon

Traditionnellement, un processus démon est défini comme un processus dont le parent est le processus d’initialisation du système et qui s’exécute en arrière-plan. Par exemple, si vous exécutiez un programme dans votre terminal, votre shell créerait un processus (au premier plan ou en arrière-plan) et le programme s’exécuterait avec votre shell en tant que parent. Ceci est un exemple de processus non-démon car son parent est votre processus shell.

Alors, comment produisez-vous un processus dont le parent est le processus init? Eh bien, un processus dont le processus parent meurt avant qu’il (l’enfant) soit sorti devient un processus orphelin. Un processus orphelin sera à son tour lié au processus init. Voila, le processus répond maintenant à la définition d’un démon.

Si vous reliez votre citation, si vous deviez bifurquer une fois puis tuer le parent, vous obtenez l’effet désiré. De même, si vous utilisez une fois un processus et que cet enfant lance un autre processus, puis tue le premier enfant, vous réalisez également l’effet souhaité tout en maintenant le processus (maintenant grand-parent) actif.

Ce n’est pas une exigence, car tout processus en arrière-plan peut être un démon. Techniquement, un processus démon dans un processus qui exécute une tâche générale non interactive. Dans un environnement Unix, un démon est généralement défini comme un processus qui présente certaines caractéristiques: pas de terminal de contrôle, pas d’umask, de répertoire de travail particulier, etc. propriétés, pour obtenir un processus complètement indépendant de tout contrôle utilisateur (sauf bien sûr root).

Cela s’applique uniquement si un utilisateur standard souhaite créer un démon. Certains autres démons standard sont créés presque normalement (voir init, launchd, etc.)

Si le parent se ferme pendant que le démon continue de s’exécuter, le démon est orphelin et le processus init adopte généralement (c.-à-d. Qu’il devient le parent).

Il y a quelques exceptions, mais il est normalement prévu qu’un processus démon descend du processus init (par exemple, le processus init lancera des démons au démarrage du système). Ainsi, si un autre processus lance un démon et se termine, il obtient l’effet souhaité.

Notez que d’autres actions sont également nécessaires, telles que la dissociation du démon de n’importe quelle fenêtre tty.

D’autres réponses expliquaient déjà ce qui se passe lorsque le parent meurt, c’est-à-dire que l’enfant est adopté par le processus init.

Mais pourquoi est-il nécessaire de créer un démon de processus? Par définition, un démon est un programme non interactif, c’est-à-dire qu’il ne doit pas être associé à un terminal. Cela garantit que le démon continue de fonctionner en arrière-plan, même lorsque l’utilisateur envoie des signaux par Control-C, le raccrochage, etc. Maintenant, comment empêcher un processus de se connecter à un terminal? Faites en sorte que init soit le parent en tuant le parent d’origine. init est un processus spécial car:

• Il n’est attaché à aucun terminal.
• C’est le premier processus (pid 1) après le démarrage du système d’exploitation, ce qui en fait le leader de la session. Notez que chaque processus UNIX appartient à un groupe de processus et qu’il appartient à son tour à une session. Le premier processus de la session devient responsable de la session.

Sous UNIX, seul le leader de session peut se connecter au terminal (ou le contrôler). Dès que vous faites init parent de votre processus, il rejoint la session d’initialisation. Comme init est le leader de la session, votre processus ne peut jamais être le leader et ne peut donc jamais être associé à un terminal. C’est ce que nous voulions, non?

Il y a d’autres façons de détacher un terminal, par exemple appeler setsid mais cela ne fait pas partie de cette discussion.