Comment est-il possible que kill -9 pour un processus sous Linux n'ait aucun effet?

vérifiez que le parent-id est vraiment 1. Si non, et c'est firefox , essayez d'abord de sudo killall -9 firefox-bin . Après cela, essayez de tuer le processus spécifique IDs individuellement avec sudo killall -9 [process-id] .

Comment est-il possible pour un processus de ne pas écouter kill -9 (neiter en tant qu'utilisateur ou root)?

si un processus est allé <defunct> et devient alors un zombie avec un parent de 1, vous ne pouvez pas le tuer manuellement; seulement init peut. Les processus zombies sont déjà morts et partis - ils ont perdu la possibilité d'être tués car ils ne sont plus des processus, seulement une entrée de table de processus et son code de sortie associé, en attente d'être collecté. Vous devez tuer le parent, et vous ne pouvez pas tuer init pour des raisons évidentes.

mais voir ici pour plus d'Informations générales. Un redémarrage sera tuer tout, naturellement.

est-il possible que ce processus soit redémarré (par exemple par init) juste au moment où vous le tuez?

Vous pouvez le vérifier facilement. Si le PID est le même après kill -9 PID alors le processus n'a pas été tué, mais s'il a changé le processus a été redémarré.

je me suis récemment pris au piège dans un piège de double fourche et avait atterri à cette page avant de finalement trouver ma réponse. Les symptômes sont identiques, même si le problème n'est pas la même:

• WYKINWYT :Ce que Vous Tuer n'Est Pas Ce que Vous avez Pensé

le code d'essai minimal est montré ci-dessous basé sur un exemple pour un démon SNMP

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

int main(int argc, char* argv[])
{
    //We omit the -f option (do not Fork) to reproduce the problem
    char * options[]={"/usr/local/sbin/snmpd",/*"-f","*/-d","--master=agentx", "-Dagentx","--agentXSocket=tcp:localhost:1706",  "udp:10161", (char*) NULL};

    pid_t pid = fork();
    if ( 0 > pid ) return -1;

    switch(pid)
    {
        case 0: 
        {   //Child launches SNMP daemon
            execv(options[0],options);
            exit(-2);
            break;
        }
        default: 
        {
            sleep(10); //Simulate "long" activity

            kill(pid,SIGTERM);//kill what should be child, 
                              //i.e the SNMP daemon I assume
            printf("Signal sent to %d\n",pid);

            sleep(10); //Simulate "long" operation before closing
            waitpid(pid);
            printf("SNMP should be now down\n");

            getchar();//Blocking (for observation only)
            break;
        }
    }
    printf("Bye!\n");
}

au cours de la première phase le principal processus (7699) lance le démon SNMP (7700) mais on peut voir que celui-ci est maintenant Défunte/Zombie . À côté nous pouvons voir un autre processus (7702) avec les options nous avons spécifié

[nils@localhost ~]$ ps -ef | tail
root       7439      2  0 23:00 ?        00:00:00 [kworker/1:0]
root       7494      2  0 23:03 ?        00:00:00 [kworker/0:1]
root       7544      2  0 23:08 ?        00:00:00 [kworker/0:2]
root       7605      2  0 23:10 ?        00:00:00 [kworker/1:2]
root       7698    729  0 23:11 ?        00:00:00 sleep 60
nils       7699   2832  0 23:11 pts/0    00:00:00 ./main
nils       7700   7699  0 23:11 pts/0    00:00:00 [snmpd] <defunct>
nils       7702      1  0 23:11 ?        00:00:00 /usr/local/sbin/snmpd -Lo -d --master=agentx -Dagentx --agentXSocket=tcp:localhost:1706 udp:10161
nils       7727   3706  0 23:11 pts/1    00:00:00 ps -ef
nils       7728   3706  0 23:11 pts/1    00:00:00 tail

après la simulation de 10 Secondes nous allons essayer de tuer le seul processus que nous connaissons (7700). Ce que nous réussissons enfin avec waitpid() . Mais le processus 7702 est toujours là

[nils@localhost ~]$ ps -ef | tail
root       7431      2  0 23:00 ?        00:00:00 [kworker/u256:1]
root       7439      2  0 23:00 ?        00:00:00 [kworker/1:0]
root       7494      2  0 23:03 ?        00:00:00 [kworker/0:1]
root       7544      2  0 23:08 ?        00:00:00 [kworker/0:2]
root       7605      2  0 23:10 ?        00:00:00 [kworker/1:2]
root       7698    729  0 23:11 ?        00:00:00 sleep 60
nils       7699   2832  0 23:11 pts/0    00:00:00 ./main
nils       7702      1  0 23:11 ?        00:00:00 /usr/local/sbin/snmpd -Lo -d --master=agentx -Dagentx --agentXSocket=tcp:localhost:1706 udp:10161
nils       7751   3706  0 23:12 pts/1    00:00:00 ps -ef
nils       7752   3706  0 23:12 pts/1    00:00:00 tail

après avoir donné un caractère au getchar() fonction de nos principaux processus se termine, mais le démon SNMP avec le pid 7002 est toujours là

[nils@localhost ~]$ ps -ef | tail
postfix    7399   1511  0 22:58 ?        00:00:00 pickup -l -t unix -u
root       7431      2  0 23:00 ?        00:00:00 [kworker/u256:1]
root       7439      2  0 23:00 ?        00:00:00 [kworker/1:0]
root       7494      2  0 23:03 ?        00:00:00 [kworker/0:1]
root       7544      2  0 23:08 ?        00:00:00 [kworker/0:2]
root       7605      2  0 23:10 ?        00:00:00 [kworker/1:2]
root       7698    729  0 23:11 ?        00:00:00 sleep 60
nils       7702      1  0 23:11 ?        00:00:00 /usr/local/sbin/snmpd -Lo -d --master=agentx -Dagentx --agentXSocket=tcp:localhost:1706 udp:10161
nils       7765   3706  0 23:12 pts/1    00:00:00 ps -ef
nils       7766   3706  0 23:12 pts/1    00:00:00 tail

Conclusion

le fait que nous ayons ignoré le mécanisme double fourche nous a fait penser que l'action de tuer n'a pas réussi. Mais en fait, nous avons simplement tué le mauvais processus !!

en ajoutant l'option - f (do Not (Double) Fork ) all go comme prévu

ps-ef / grep firefox; et vous pouvez voir 3 processus, de les tuer tous.

sudo killall -9 firefox

devrait fonctionner

EDITION: [PID] a changé de firefox

vous pouvez aussi faire un pstree et tuer le parent. Cela fait en sorte que vous obtenez l'arbre entier de processus offensant et pas seulement la feuille.