J'essaie de créer un conteneur de processus. Le conteneur déclenchera d'autres programmes. Par exemple - un script bash qui lance l'exécution de tâches en arrière-plan avec l'utilisation de "&".
La caractéristique importante que je recherche est la suivante :lorsque je tue le conteneur, tout ce qui a été créé sous celui-ci doit être tué. Pas seulement les enfants directs, mais aussi leurs descendants.
Quand j'ai commencé ce projet, j'ai cru à tort que lorsque vous tuiez un processus, ses enfants étaient automatiquement tués aussi. J'ai demandé conseil à des personnes qui avaient la même idée erronée. Bien qu'il soit possible d'attraper un signal et de transmettre la mise à mort aux enfants, ce n'est pas ce que je recherche ici.
Je crois que ce que je veux être réalisable, parce que lorsque vous fermez un xterm, tout ce qui fonctionnait à l'intérieur est tué à moins qu'il n'ait été nohup'd. Cela inclut les processus orphelins. C'est ce que je cherche à recréer.
J'ai une idée que ce que je cherche implique des sessions unix.
S'il existait un moyen fiable d'identifier tous les descendants d'un processus, il serait utile de pouvoir également leur envoyer des signaux arbitraires. par exemple. SIGUSR1.
Réponse acceptée :
Si vous envoyez un signal à un processus, ce processus est tué. Je me demande comment la rumeur selon laquelle tuer un processus tue également d'autres processus a commencé, cela semble particulièrement contre-intuitif.
Il existe cependant des moyens de tuer plus d'un processus. Mais vous n'enverrez pas de signal à un processus. Vous pouvez tuer un groupe de processus entier en envoyant un signal à -1234 où 1234 est le PGID (process group ID), qui est le PID du leader du groupe de processus. Lorsque vous exécutez un pipeline, l'ensemble du pipeline démarre en tant que groupe de processus (les applications peuvent modifier cela en appelant setpgid ou setpgrp ).
Lorsque vous démarrez des processus en arrière-plan (foo & ), ils sont dans leur propre groupe de processus. Les groupes de processus sont utilisés pour gérer l'accès au terminal ; normalement, seul le groupe de processus de premier plan a accès au terminal. Les tâches d'arrière-plan restent dans la même session, mais il n'y a aucune possibilité de tuer une session entière ou même d'énumérer les groupes de processus ou les processus dans une session, donc cela n'aide pas beaucoup.
Lorsque vous fermez un terminal, le noyau envoie le signal SIGHUP à tous les processus qui l'ont comme terminal de contrôle. Ces processus forment une session, mais toutes les sessions n'ont pas de terminal de contrôle. Pour votre projet, une possibilité est donc de démarrer tous les processus dans leur propre terminal, créé par script, écran, etc. Tuez le processus de l'émulateur de terminal pour tuer les processus contenus (en supposant qu'ils n'aient pas fait sécession avec setsid ).
Vous pouvez fournir plus d'isolation en exécutant les processus en tant que leur propre utilisateur, qui ne fait rien d'autre. Ensuite, il est facile de tuer tous les processus :exécutez kill (l'appel système ou l'utilitaire) en tant qu'utilisateur et utilisez -1 comme argument PID pour tuer, ce qui signifie "tous les processus de cet utilisateur".
Vous pouvez fournir encore plus d'isolation, mais avec beaucoup plus de configuration en exécutant les processus contenus dans un conteneur réel.