“Tuer <PID>” ne tue pas vraiment le processus, pourquoi?

J'essaie d'améliorer mes compétences en ligne de commande et j'ai rencontré un problème où je ne peux pas tuer un processus. Je tape kill 2200où 2200 est mon PID et le processus n'est pas tué. Après quelques minutes, l'attente est toujours dans le topet ps aux. J'ai même essayé de le taper avec sudo - aucun résultat.

Des idées pourquoi ce serait comme ça?

MODIFIER

J'ai trouvé une dépendance étrange, où fgmet à jour la liste des processus:

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2202 pts/0    00:00:00 top
 2258 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2200 pts/0    00:00:00 top
 2620 pts/0    00:00:00 ps
x@xxx:/etc/grub.d$ fg
top

x@xxx:/etc/grub.d$ ps
  PID TTY          TIME CMD
 1723 pts/0    00:00:00 bash
 2621 pts/0    00:00:00 ps

Les processus peuvent ignorer certains signaux. Si vous envoyez SIGKILL, il ne pourra pas l’ignorer (ni l’attraper pour le nettoyer). Essayer:

kill -9 {PID}

En savoir plus en lisant la page de manuel:

man kill

Si killest appelé sans paramètre, il envoie le numéro de signal 15 ( SIGTERM). Ce signal peut être ignoré par le processus. Ce signal indique au processus de nettoyer ses affaires et de se terminer correctement par lui-même. C'est la bonne façon.

Vous pouvez également "envoyer" le numéro de signal 9 ( SIGKILL) qui ne peut pas être ignoré par le processus. Le processus ne le reconnaîtra même pas, car le noyau termine le processus, pas le processus lui-même. C'est la mauvaise façon.

On dit kill -9 <pid>toujours travaille. C'est une incrédulité . Il y a des situations où même kill -9ne tue pas le processus. Par exemple, lorsqu'un processus a l'état D(veille ininterrompue). Un processus entre dans cet état chaque fois qu'il attend une entrée / sortie (normalement pas très long). Ainsi, si un processus attend une entrée / sortie (sur un disque dur défectueux par exemple) et qu'il n'est pas programmé correctement (avec un délai d'attente), vous ne pouvez tout simplement pas arrêter le processus . Peut importe ce que vous faites. Vous pouvez simplement essayer de rendre le fichier accessible pour que le processus continue.

Bien que son nom, kill ne tue pas réellement les processus, il lui envoie des signaux. De la page de manuel:

kill - send a signal to a process

Le signal par défaut envoyé par kill [pid]est SIGTERM, qui demande généralement mais pas nécessairement la fin du processus. Il est tout à fait possible d'écrire un programme qui joue une mélodie joyeuse lorsque vous lui envoyez le signal SIGTERM , mais cela n'est pas recommandé.

SIGHUP est un autre signal commun qui est souvent utilisé pour demander à un programme de relire ses fichiers de configuration.

Si vous voulez vraiment tuer un programme, vous devez utiliser le signal SIGKILL en le faisant kill -9 [pid].

Il semble que vous suspendez un processus (peut-être en appuyant sur Ctrl-Z dans le terminal). Dans cet état, votre processus ne répondra pas à un SIGTERM car il est gelé. Exécuter 'fg' libère le processus, ce qui lui permet de capter le signal et de se terminer automatiquement. Cela pourrait expliquer pourquoi «fg» apparaît pour mettre à jour la liste de processus.

À partir de C ++, j'ai exécuté:

kill(4024, SIGKILL);

Et sur un terminal Linux (Ubuntu),

$ ps -ax | grep my_su

La sortie était:

4024 pts/1    Z+     0:00 [my_subscriber] <defunct>

Apparemment, il (4024) survit encore. Cependant, dès que j'ai mis fin au processus parent qui appelait l'instruction "kill" ci-dessus, 4024 n'apparaissait plus. Maintenant, je juge que le processus "défunt" n’est plus qu’une ligne affichée et décide de l’ignorer. J'espère que mon expérience pourra aider quelqu'un là-bas. À votre santé!

Vous pouvez également utiliser kill -lpour afficher les signaux pris en charge par votre architecture et en savoir plus sur le signal que vous souhaitez utiliser pour envoyer correctement un signal.

Remarque: comme d'autres l'ont peut-être mentionné, l'utilisation de kill -9 {PID}n'est pas recommandée à moins que ce ne soit un processus zombie. une fois qu'un processus reçoit un SIGKILL va s'arrêter immédiatement sans nettoyage ou toute autre procédure appropriée.

C’est ce que j’utilisais jadis pour utiliser localhost sur le port 80 (Par clular angulaire) Obtenir les informations de l’application en cours sur le port 80

sudo lsof -i tcp:80

After That 
sudo kill -9 3348

où 3348est le pid du processus en cours