Changer le processus parent d'un processus?

14

Est-il possible de changer le processus parent d'un processus? Si oui, comment?

Par exemple,

  • comment screenparvient-il à attacher une screensession et les processus en cours d'exécution à différents processus shell? Y a-t-il un changement de processus parent?

  • Il me semble avoir entendu parler d'autres façons de changer le processus shell dans lequel un programme est en cours d'exécution, mais je ne me souviens pas. Y a-t-il également un changement de processus parent du programme?

  • J'ai pensé disownqu'un processus change le processus parent du processus, simplement parce que son nom l' disownindique. Mais j'ai trouvé que ce n'était pas vrai.

  • Le client Emacs peut se connecter au serveur emacs sur un onglet de terminal différent. Y a-t-il un changement de processus parent?

process gnu-screen job-control disown Tim
la source
disownsupprime simplement un enfant donné de la liste interne des processus enfants d'un shell. Le PPID de l'enfant reste celui de la coquille. Le shell a oublié qu'il n'a jamais démarré cet enfant, mais le noyau s'en souvient.
Warren Young
Le processus se souvient-il de son parent?
Tim
S'il veut savoir, il appelle getppid(2), un appel système et les appels système sont gérés par le noyau. Un programme peut être confondu en émettant cet appel, en enregistrant la valeur, puis en utilisant cette valeur après que sa filiation a changé. Il y a une chance d'une condition de course ici.
Warren Young
Cela ressemble à une nouvelle fonctionnalité intéressante du noyau.
ChuckCottrill

Réponses:

14

L'identifiant du processus parent (ppid) d'un processus ne peut pas être modifié en dehors du noyau; il n'y a pas d'appel système setppid. Le noyau ne changera le ppid en (pid) 1 qu'après la fin du processus parent - si le processus n'a pas répondu à un signal indiquant que le parent s'est terminé. Pour que cela se produise, les besoins du processus d'avoir ignoré différents signaux ( SIGHUP, SIGTERM, etc.) au préalable.

screen(1)dispose d'un moyen très élégant de gérer le détachement et le rattrapage. Lorsque vous démarrez pour la première fois screen, vous démarrez en fait une interface utilisateur (ui), qui par défaut créera un démon (le gestionnaire de session). Ce démon n'a pas de terminal associé, un nouveau groupe de processus ( setpgrp(2)), un nouvel identifiant de session ( setsid(2)). Le démon, fonctionnant en tant que SCREEN, créera alors des sous-processus connectés aux pseudo-terminaux ( pty), puis multiplexera les données des ptys et des ui ( screen). Les sous-processus pensent parler avec un vrai terminal.

Si l'interface utilisateur se screentermine, le démon SCREENsera toujours en cours d'exécution, en tamponnant les données, en gérant les signaux, en attendant une nouvelle interface utilisateur, etc. car il s'agit d'un groupe de processus différent et dans sa propre session. Lorsque vous vous reconnectez avec une nouvelle interface utilisateur screen, le démon continue de multiplexer comme il le faisait auparavant. Le démon s'exécutera et continuera jusqu'à ce que tous les sous-processus se terminent, soient tués, qu'un bogue fatal se produise ou que l'hôte redémarre.

Arcege
la source
Merci. J'ai ajouté "Le client Emacs peut se connecter au serveur emacs sur un autre onglet de terminal. Y a-t-il un changement de processus parent?"
Tim
1
Chaque processus n'a qu'un seul parent, jusqu'à ce que le parent meure ou qu'il meure. S'il meurt, le point est sans objet. Si le parent décède, le PPID devient 1, le initprocessus. C'est la seule fois où le processus parent changerait - à la fin du processus parent. La connexion via la communication interprocessus (tuyaux, sockets, etc.) n'a aucun effet sur le PPID.
Arcege
Comment Emacs attache-t-il un client à un serveur dans différents onglets de terminal?
Tim
Le serveur écouterait sur un socket (généralement un fichier socket de domaine UNIX) en attente de connexions. Le ou les clients ouvriraient une connexion sur ce socket. Les onglets ne sont pas pertinents pour la communication entre le client et le serveur, il peut y avoir différents onglets, différents émulateurs terminaux (xterm vs rxvt vs terminal), ou peuvent être des xemacs. Chaque client sait où se connecter, il peut donc être de n'importe où.
Arcege
1
L'identifiant du processus parent ne devient pas toujours 1. Cet absolutisme de sagesse reçu est erroné depuis plus de 3 ans maintenant.
JdeBP
-2

Je comprends. Vous devez changer le noyau pour écrire un module pour le faire! Je pense que ce sera utile dans certains cas. Par exemple, vous faites un long travail acharné, ils prennent de nombreuses ressources pendant des heures ... Et lorsque le système ne répond pas (comme d'habitude dans ce cas), vous effectuez des actions imprévisibles (car vous devez le faire et vous n'êtes pas sûr de cliquer sur une souris au bon endroit pour que le système ne réponde pas longtemps) et tue accidentellement le processus parent. Le système tue généralement tous les enfants! Mais si le processus enfant est root et parent uniquement, l'utilisateur et l'action ordinaux rendent également l'utilisateur ordinal ce processus non tué en aucun cas! Et son parent sera init avec le PID 1. Et après que le système ait enfin répondu, vous voulez restaurer la hiérarchie. Mais tu ne peux pas !!! Standard, vous démarrez le système de mise à niveau en tant que root à partir du terminal en tant qu'utilisateur ordinaire avec su. Pourquoi? Donc, pour obtenir toutes les erreurs et avertissements sur la console. L'utilitaire de mise à niveau est particulièrement GUI. Ils obtiennent ces informations pour rien ... Je me souviens que dans Windows OS, cela peut être fait. Il existe des fonctions spéciales WinAPI. Pourquoi sous Linux, cela ne peut pas être fait? Ce n'est pas clair ... C'est simple !!!

user239712
la source