Sous UNIX, lorsqu'un processus parent disparaît, je pensais que tous les processus enfants réinitialisaient init comme parent. N'est-ce pas correct tout le temps? Y a-t-il des exceptions?
Sous UNIX, lorsqu'un processus parent disparaît, je pensais que tous les processus enfants réinitialisaient init comme parent. N'est-ce pas correct tout le temps? Y a-t-il des exceptions?
Réponses:
Passer de mon commentaire à une réponse ... Je ne pense pas qu'il y ait d'exceptions.
Trouvé "parfois le processus parent est tué avant que son enfant ne soit tué. Dans ce cas, le processus" parent de tous les processus " initdevient le nouveau PPID (ID de processus parent). Parfois, ces processus sont appelés processus orphelin". la source
De la même manière est décrite dans le blog d'IBM : "Le parent meurt ou se fait tuer avant l'enfant. Dans le scénario ci-dessus, le processus enfant devient le processus orphelin (car il a perdu son parent). Sous Linux, le initprocessus vient à la rescousse du orphelin les traite et les adopte. Cela signifie qu'une fois qu'un enfant a perdu son parent, le initprocessus devient son nouveau processus parent. "
Trois réponses écrites en 2014, toutes disant que sous Unices et sous Linux le processus est reparent au processus # 1 sans exception. Trois mauvaises réponses. ☺
Comme le dit le SUS , cité dans l'une des autres réponses ici, je ne vais donc pas le citer à nouveau, le processus parent des enfants orphelins est défini sur un processus défini par la mise en œuvre . Cristian Ciupitu a raison de consulter la documentation Linux pour voir ce que l'implémentation définit. Mais il est induit en erreur par cette documentation, qui est incohérente et pas à jour.
Deux ans avant l'écriture de ces trois réponses, et il y a très peu de temps, il y a trois ans au moment de la rédaction de cette réponse, le noyau Linux a changé. Les développeurs de systemd ont ajouté la possibilité pour les processus de se définir comme des "sous-utilisateurs". À partir de Linux 3.4, les processus peuvent émettre l' prctl()appel système avec l' PR_SET_CHILD_SUBREAPERoption, et en conséquence, ce n'est pas le processus n ° 1 qui deviendra le parent de l'un de leurs processus descendants orphelins. La page de manuel deprctl() est à jour, mais les autres pages de manuel n'ont pas été mises à jour et rendues cohérentes.
Dans la version 10.2, FreeBSD a acquis la même capacité, étendant son procctl()appel système existant avec PROC_REAP_ACQUIREet PROC_REAP_RELEASEoptions. Il a adopté ce mécanisme de DragonFly BSD; qui l'a gagné dans la version 4.2, initialement nommée reapctl()mais renommée lors du développement en procctl().
Il existe donc des exceptions, et des exceptions assez importantes: sous Linux, FreeBSD / PC-BSD et DragonFly BSD, le processus parent des enfants orphelins est défini sur le processus ancêtre le plus proche de l'enfant qui est marqué comme sous-segment ou processus # 1. s'il n'y a pas de sous-processus ancêtre. Divers utilitaires de supervision de démons - y compris systemd (celui dont les développeurs ont mis cela dans le noyau Linux en premier lieu), upstart et le nosh service-manager- l'utilisent déjà.
Si un tel superviseur démon traite pas # 1, et il engendre un service comme une session de connexion interactive, et que l' une de session ne l'affaire (tout à fait une totale aberration) de tenter de « daemonize » par double- fork()ment , puis un processus de volonté finir comme un enfant du superviseur du démon, pas du processus # 1. S'attendre à pouvoir générer directement des démons à partir de sessions de connexion est bien sûr une erreur fondamentale. Mais c'est une autre réponse.
procctl(). Pages du manuel DragonFly BSD. § 2.Selon la exitpage de manuel de The Single UNIX® Specification, Version 2:
L'ID de processus parent de tous les processus enfants et processus zombies existants du processus appelant est défini sur l'ID de processus d'un processus système dépendant de l'implémentation. Autrement dit, ces processus sont hérités par un processus système spécial.
Pour la plupart des variantes Unix, ce processus spécial est init(PID 1).
La wait(2)page de manuel Linux le confirme:
Si un processus parent se termine, ses enfants "zombies" (le cas échéant) sont adoptés par init (8), qui effectue automatiquement une attente pour supprimer les zombies.
Les pages de manuel FreeBSD wait(2), NetBSD wait(2), OpenBSD wait(2)et Mac OS X le wait(2)confirment également:
Si un processus parent se termine sans attendre la fin de tous ses processus enfants, les processus enfants restants se voient attribuer l'ID de processus parent 1 (l'ID de processus init).
La wait(3C)page de manuel Oracle Solaris 11.1 le confirme également:
Si un processus parent se termine sans attendre la fin de ses processus enfants, l'ID de processus parent de chaque processus enfant est défini sur 1, le processus d'initialisation héritant des processus enfants; voir
Intro(2).
Je ne le crois pas. Cela va toujours au processus init.