Pourquoi le processus enfant est-il toujours vivant après la mort du processus parent sous Linux?
Quelqu'un m'a dit que lorsque vous tuiez un processus parental sous Linux, l'enfant mourrait.
Mais j'en doute. J'ai donc écrit deux scripts bash, où father.shinvoquerait child.sh
Voici mon script:
Maintenant, je lance bash father.sh, vous pouvez le vérifier ps -alf 
Ensuite, j'ai tué le father.sh par kill -9 24588, et j'ai deviné que le processus enfant devait être terminé mais malheureusement je me trompais. 
Quelqu'un pourrait-il expliquer pourquoi?
tHX
Non, lorsque vous tuez un processus seul, il ne tuera pas les enfants.
Vous devez envoyer le signal au groupe de processus si vous voulez que tous les processus d'un groupe donné reçoivent le signal
kill -9 -parentpid
Sinon, les orphelins seront liés à init, comme le montre votre troisième capture d'écran (le PPID de l'enfant est devenu 1).
Généralement, tuer le parent tue l'enfant.
La raison pour laquelle vous voyez l'enfant encore vivant après avoir tué le père est que l'enfant ne mourra qu'après avoir choisi de gérer l'événement SIGKILL. Il n'a pas à le gérer tout de suite. Votre script exécute une commande sleep (), qui ne se réveillera pour gérer aucun événement tant que la mise en veille n'est pas terminée.
Pourquoi PPID # 1? Le parent est décédé et n'est plus dans la table de processus. child.sh n'est pas lié inexplicablement à initier maintenant. Il n'a tout simplement aucun parent en cours d'exécution. Le fait de dire qu'il est lié à init donne l'impression que si nous quittons en quelque sorte init, cet init a le contrôle de l'arrêt du processus. Cela donne également l'impression que tuer un parent fera du grand-parent le propriétaire d'un enfant. Les deux ne sont pas vrais. Ce processus enfant existe toujours dans la table de processus et est en cours d'exécution, mais aucun nouvel événement basé sur son ID de processus ne sera traité jusqu'à ce qu'il gère SIGKILL. Ce qui signifie que l'enfant est un pré-zombie, marchant mort, en danger d'être étiqueté.
Tuer dans le groupe de processus est différent et est utilisé pour tuer les frères et sœurs et parent par le groupe de processus #. Il est probablement également important de noter que "tuer un processus" n'est pas "tuer" en soi, à la manière humaine, où vous vous attendez à ce que le processus soit détruit et que toute la mémoire soit rendue comme si elle ne l'avait jamais été. Il envoie simplement un événement particulier, parmi beaucoup d'autres, au processus pour qu'il le gère. Si le processus ne le gère pas correctement, après un certain temps, le système d'exploitation viendra et "nettoiera" de force.
Cela (tuer) ne se produit pas immédiatement car l'enfant (ou même le parent) aurait pu écrire quelque chose sur le disque et attendre que les E/S se terminent ou effectuer une autre tâche critique qui pourrait compromettre la stabilité du système ou l'intégrité des fichiers.
-bash: kill: (-123) - Aucun processus de ce type
Dans une session Terminal.app interactive, le numéro d'identification du groupe de processus de premier plan et le numéro d'identification du groupe de processus d'arrière-plan sont différents par conception lorsque le mode de contrôle des travaux/moniteur est activé. En d'autres termes, si vous mettez en arrière-plan une commande dans une session Terminal.app activée par le contrôle des travaux, le pid $! Du processus en arrière-plan est en fait un nouveau numéro d'identification de groupe de processus (pgid).
Dans un script n'ayant aucun contrôle de tâche activé, cependant, cela peut ne pas être le cas! Le pid du processus en arrière-plan peut ne pas être un nouveau pgid mais un pid normal! Et c'est ce qui provoque le message d'erreur -bash: kill: (-123) - No such process, essayant de tuer un groupe de processus mais spécifiant uniquement un pid normal (au lieu d'un pgid) à la commande kill.
# the following code works in Terminal.app because $! == $pgid
{
sleep 100 &
IFS=" " read -r pgid <<EOF
$(ps -p $! -o pgid=)
EOF
echo $$ $! $pgid
sleep 10
kill -HUP -- -$!
#kill -HUP -- -${pgid} # use in script
}
pkill -TERM -P <ProcessID>
Cela tuera à la fois le parent et l'enfant