Ne peut pas tuer un processus de sommeil

13

Je ne semble pas être en mesure de tuer -9 un processus qui est dans un état de sommeil interruptible (S):

[root@jupiter ~]# ps -elf | grep yum
4 S root     16790     1  0  75   0 - 73779 -      Jan15 ?        00:00:04 /usr/bin/python /usr/bin/yum -y install python-pip
[root@jupiter ~]# kill -9 16790
[root@jupiter ~]# ps -elf | grep yum
4 S root     16790     1  0  75   0 - 73779 -      Jan15 ?        00:00:04 /usr/bin/python /usr/bin/yum -y install python-pip

Comment est-ce possible? Existe-t-il un moyen de tuer le processus sans redémarrer?

BOUNTY: Je suis vraiment plus intéressé par une explication de la façon dont cela est possible.

MISE À JOUR: Ceci est la sortie de lsof:

[root @ jupiter ~] # lsof -p 16790
UTILISATEUR PID UTILISATEUR TYPE FD TAILLE / NOM DU NŒUD DE L'APPAREIL
yum 16790 root cwd DIR 1166,56842 4096 16886249 / home / del
miam 16790 root rtd DIR 253,0 4096 2 /
miam 16790 root txt REG 253,0 8304 336177337 / usr / bin / python
miam 16790 racine mem REG 253,0 144776 346128569 /lib64/ld-2.5.so
miam 16790 racine mem REG 253,0 1718232 346128573 /lib64/libc-2.5.so
miam 16790 racine mem REG 253,0 23360 346128599 /lib64/libdl-2.5.so
miam 16790 racine mem REG 253,0 145872 346128584 /lib64/libpthread-2.5.so
miam 16790 racine mem REG 253,0 615136 346128602 /lib64/libm-2.5.so
miam 16790 root mem REG 253,0 1244792 336171087 /usr/lib64/libpython2.4.so.1.0
miam 16790 racine mem REG 253,0 95464 346128744 /lib64/libselinux.so.1
miam 16790 racine mem REG 253,0 53448 346128750 /lib64/librt-2.5.so
miam 16790 root mem REG 253,0 13960 336187564 /usr/lib64/libplds4.so
miam 16790 root mem REG 253,0 58400 346128752 /lib64/libgcc_s-4.1.2-20080825.so.1
miam 16790 racine mem REG 253,0 78384 336173796 /usr/lib64/libelf-0.137.so
miam 16790 racine mem REG 253,0 1139672 336187570 /usr/lib64/librpmdb-4.4.so
miam 16790 racine mem REG 253,0 407792 336187568 /usr/lib64/librpmio-4.4.so
miam 16790 racine mem REG 253,0 233144 336171420 /usr/lib64/libnspr4.so
miam 16790 racine mem REG 253,0 375656 336187569 /usr/lib64/libsqlite3.so.0.8.6
miam 16790 racine mem REG 253,0 17992 336187563 /usr/lib64/libplc4.so
miam 16790 racine mem REG 253,0 386784 336187571 /usr/lib64/librpm-4.4.so
miam 16790 racine mem REG 253,0 154776 336170228 /usr/lib64/librpmbuild-4.4.so
miam 16790 root mem REG 253,0 647608 346128759 /lib64/libglib-2.0.so.0.1200.3
miam 16790 racine mem REG 253,0 1297136 336176959 /usr/lib64/libxml2.so.2.6.26
miam 16790 racine mem REG 253,0 15584 346128756 /lib64/libtermcap.so.2.0.8
miam 16790 racine mem REG 253,0 1234328 336187566 /usr/lib64/libnss3.so
miam 16790 racine mem REG 253,0 18152 346128670 /lib64/libutil-2.5.so
miam 16790 root mem REG 253,0 34240 336177071 /usr/lib64/libpopt.so.0.0.0
miam 16790 racine mem REG 253,0 67792 336187567 /usr/lib64/libbz2.so.1.0.3
miam 16790 racine mem REG 253,0 143144 346128763 /lib64/libexpat.so.0.5.0
miam 16790 root mem REG 253,0 56434416 336184082 / usr / lib / locale / locale-archive
miam 16790 root mem REG 253,0 132656 336560181 /usr/lib64/python2.4/site-packages/rpm/_rpmmodule.so
miam 16790 racine mem REG 253,0 154016 336187565 /usr/lib64/libnssutil3.so
miam 16790 root mem REG 253,0 96885 345638632 /usr/local/greenplum-loaders-3.3.0.0-build-3/lib/libz.so.1.2.3
miam 16790 racine mem REG 253,0 247496 346128741 /lib64/libsepol.so.1
miam 16790 racine mem REG 253,0 369144 336168883 /usr/lib64/libsoftokn3.so
miam 16790 racine mem REG 253,0 312336 336178453 /usr/lib64/libfreebl3.so
miam 16790 root mem REG 253,0 20240 336530067 /usr/lib64/python2.4/lib-dynload/timemodule.so
miam 16790 root mem REG 253,0 25048 336529953 /usr/lib64/python2.4/lib-dynload/stropmodule.so
miam 16790 root mem REG 253,0 18984 336530051 /usr/lib64/python2.4/lib-dynload/cStringIO.so
miam 16790 root mem REG 253,0 21816 336529943 /usr/lib64/python2.4/lib-dynload/collectionsmodule.so
miam 16790 root mem REG 253,0 52152 336530044 /usr/lib64/python2.4/lib-dynload/_socketmodule.so
miam 16790 root mem REG 253,0 17200 336530045 /usr/lib64/python2.4/lib-dynload/_ssl.so
miam 16790 racine mem REG 253,0 315080 346128749 /lib64/libssl.so.0.9.8e
miam 16790 root mem REG 253,0 1366912 346128748 /lib64/libcrypto.so.0.9.8e
miam 16790 racine mem REG 253,0 190976 336187552 /usr/lib64/libgssapi_krb5.so.2.2
miam 16790 racine mem REG 253,0 613928 336184245 /usr/lib64/libkrb5.so.3.3
miam 16790 root mem REG 253,0 11760 346128747 /lib64/libcom_err.so.2.1
miam 16790 root mem REG 253,0 153720 336181723 /usr/lib64/libk5crypto.so.3.1
miam 16790 root mem REG 253,0 35984 336177832 /usr/lib64/libkrb5support.so.0.1
miam 16790 racine mem REG 253,0 9472 346128681 /lib64/libkeyutils-1.2.so
miam 16790 racine mem REG 253,0 92816 346128730 /lib64/libresolv-2.5.so
miam 16790 root mem REG 253,0 75384 336530050 /usr/lib64/python2.4/lib-dynload/cPickle.so
miam 16790 root mem REG 253,0 23736 336530064 /usr/lib64/python2.4/lib-dynload/structmodule.so
miam 16790 root mem REG 253,0 27336 336528958 /usr/lib64/python2.4/lib-dynload/operator.so
miam 16790 root mem REG 253,0 21520 336529958 /usr/lib64/python2.4/lib-dynload/zlibmodule.so
miam 16790 root mem REG 253,0 37944 336528952 /usr/lib64/python2.4/lib-dynload/itertoolsmodule.so
miam 16790 root mem REG 253,0 21528 336528929 /usr/lib64/python2.4/lib-dynload/_localemodule.so
miam 16790 root mem REG 253,0 21208 336529939 /usr/lib64/python2.4/lib-dynload/binascii.so
miam 16790 root mem REG 253,0 12080 336530062 /usr/lib64/python2.4/lib-dynload/shamodule.so
miam 16790 root mem REG 253,0 13168 336530058 /usr/lib64/python2.4/lib-dynload/md5module.so
miam 16790 root mem REG 253,0 18000 336529947 /usr/lib64/python2.4/lib-dynload/mathmodule.so
miam 16790 root mem REG 253,0 12504 336529934 /usr/lib64/python2.4/lib-dynload/_randommodule.so
miam 16790 root mem REG 253,0 15320 336528948 /usr/lib64/python2.4/lib-dynload/fcntlmodule.so
miam 16790 root mem REG 253,0 32816 336530049 /usr/lib64/python2.4/lib-dynload/bz2.so
miam 16790 root mem REG 253,0 8608 336529946 /usr/lib64/python2.4/lib-dynload/grpmodule.so
miam 16790 root mem REG 253,0 38696 336529819 /usr/lib64/python2.4/site-packages/cElementTree.so
miam 16790 root mem REG 253,0 42672 336530047 /usr/lib64/python2.4/lib-dynload/arraymodule.so
miam 16790 root mem REG 253,0 9368 336528915 /usr/lib64/python2.4/lib-dynload/_bisect.so
miam 16790 root mem REG 253,0 74992 336529944 /usr/lib64/python2.4/lib-dynload/datetime.so
miam 16790 root mem REG 253,0 372912 336560510 /usr/lib64/python2.4/site-packages/M2Crypto/__m2crypto.so
miam 16790 root mem REG 253,0 7120 336529937 /usr/lib64/python2.4/lib-dynload/_weakref.so
miam 16790 root mem REG 253,0 17496 336528966 /usr/lib64/python2.4/lib-dynload/selectmodule.so
miam 16790 root mem REG 253,0 46448 336528961 /usr/lib64/python2.4/lib-dynload/pyexpat.so
miam 16790 root mem REG 253,0 33896 336529820 /usr/lib64/python2.4/site-packages/_sqlite.so
miam 16790 root mem REG 253,0 41784 336530075 /usr/lib64/python2.4/site-packages/_sqlitecache.so
miam 16790 root mem REG 253,0 25104 336530066 /usr/lib64/python2.4/lib-dynload/termios.so
miam 16790 root mem REG 253,0 7280 336530065 /usr/lib64/python2.4/lib-dynload/syslog.so
miam 16790 root mem REG 253,0 25464 336265457 /usr/lib64/gconv/gconv-modules.cache
miam 16790 root mem REG 253,0 66544 336528926 /usr/lib64/python2.4/lib-dynload/_cursesmodule.so
miam 16790 root mem REG 253,0 380336 336181932 /usr/lib64/libncurses.so.5.5
miam 16790 root mem REG 253,0 405880 336529957 /usr/lib64/python2.4/lib-dynload/unicodedata.so
miam 16790 root mem REG 253,0 24576 236520047 /var/lib/rpm/__db.001
miam 16790 root mem REG 253,0 53880 346128424 /lib64/libnss_files-2.5.so
miam 16790 root mem REG 253,0 23736 346128408 /lib64/libnss_dns-2.5.so
miam 16790 root mem REG 253,0 1318912 236520050 /var/lib/rpm/__db.002
miam 16790 racine mem REG 253,0 663552 236520051 /var/lib/rpm/__db.003
miam 16790 root mem REG 253,0 769074 336174965 /usr/share/locale/en_US/LC_MESSAGES/redhat-dist.mo
miam 16790 racine 0u CHR 136,8 0t0 10 / dev / pts / 8 (supprimé)
miam 16790 racine 1u CHR 136,8 0t0 10 / dev / pts / 8 (supprimé)
miam 16790 racine 2u CHR 136,8 0t0 10 / dev / pts / 8 (supprimé)
yum 16790 root 3u unix 0xffff8104388d2e40 0t0 4675113 socket
miam 16790 racine 4w REG 253,0 0 236522326 /var/log/yum.log
miam 16790 racine 5u REG 253,0 605184 236520025 /var/cache/yum/WANdisco-dev/primary.xml.gz.sqlite
miam 16790 root 6u REG 253,0 20480 236524002 /var/cache/yum/addons/primary.sqlite.old.tmp (supprimé)
miam 16790 root 7u REG 253,0 12578816 236519970 /var/cache/yum/base/primary.xml.gz.sqlite.old.tmp (supprimé)
miam 16790 racine 8u REG 253,0 17972224 236523993 /var/cache/yum/epel/317109b44f1b0b40d910dc60c9080e62c7f4b16a-primary.sqlite.old.tmp (supprimé)
miam 16790 root 9u REG 253,0 967680 236524055 /var/cache/yum/extras/primary.sqlite.old.tmp (supprimé)
miam 16790 racine 10u REG 253,0 459776 246415366 /var/cache/yum/pgdg92/primary.sqlite.old.tmp (supprimé)
miam 16790 root 11u REG 253,0 4927488 236524060 /var/cache/yum/updates/primary.sqlite.old.tmp (supprimé)
miam 16790 root 12r REG 253,0 65204224 236519434 / var / lib / rpm / Packages
miam 16790 racine 13r REG 253,0 45056 236519438 / var / lib / rpm / Nom
yum 16790 root 14u IPv4 4675317 0t0 TCP jupiter.example.com:33597->riksun.riken.go.jp:http (ESTABLISHED)
miam 16790 root 15u IPv4 4675939 0t0 TCP jupiter.example.com:52708->freedom.itsc.cuhk.edu.hk:http (CLOSE_WAIT)
miam 16790 root 16r REG 253,0 65204224 236519434 / var / lib / rpm / Packages
miam 16790 racine 17r REG 253,0 45056 236519438 / var / lib / rpm / Nom
miam 16790 root 18r REG 253,0 12288 236519440 / var / lib / rpm / Pubkeys
miam 16790 racine 20r FIFO 0,6 0t0 4676024 tuyau
miam 16790 racine 24w FIFO 0,6 0t0 4676024 tuyau
del
la source
Tuez les autres processus qui manipulent le même verrou et il sera probablement débridé.
David Schwartz
@David - Je ne peux tuer aucun des processus yum dans la liste des processus ci-dessus; ils ont tous le même problème.
du
J'ai supprimé les lignes supplémentaires car elles n'ajoutaient plus d'informations et rendaient la lecture de votre message plus difficile.
terdon
@slm - lsof affiche les sockets TCP vers riksun.riken.go.jp:80 (ESTABLISHED) et freedom.itsc.cuhk.edu.hk:80 (CLOSE_WAIT). Je suppose que ça pourrait être ça?
du
@slm - Veuillez voir ma question mise à jour.
du

Réponses:

18

Un processus à l'état S ou D est généralement dans un appel système bloquant, comme la lecture ou l'écriture dans un fichier ou le réseau, en attente de la fin d'un programme appelé, ou en attendant des sémaphores ou d'autres primitives de synchronisation. Il se mettra en veille en attendant.

Vous ne pouvez pas le "réveiller" - il ne se poursuivra que lorsque les données / ressources qu'il attend seront disponibles. C'est tout à fait normal et attendu, et seulement un problème lorsque vous essayez de le tuer.

Vous pouvez essayer et utiliser strace -p pidpour savoir quel appel système est en cours pour le processus pid.

De wikipedia :

Un état de sommeil sans interruption est un état de sommeil qui ne traitera pas immédiatement un signal. Il ne se réveillera qu'à la suite de la disponibilité d'une ressource attendue ou après un délai d'expiration pendant cette attente (si spécifié lors de la mise en veille). Il est principalement utilisé par les pilotes de périphériques en attente d'E / S disque ou réseau (entrée / sortie). Lorsque le processus est en sommeil sans interruption, les signaux accumulés pendant le sommeil seront remarqués lorsque le processus reviendra de l'appel système ou de l'interruption.

Un processus bloqué dans un appel système est en veille sans interruption, qui, comme son nom l'indique, est vraiment ininterrompu même par root.

Normalement, les processus ne peuvent pas bloquer SIGKILL. Mais le code du noyau peut et les processus exécutent le code du noyau lorsqu'ils appellent des appels système, pendant lesquels le code du noyau bloque tous les signaux. Ainsi, si un appel système se bloque indéfiniment, il peut ne pas être possible de tuer le processus. Le SIGKILL ne prend effet que lorsque le processus termine l'appel système.

harrymc
la source
2
Je pensais que seuls les processus de sommeil ininterrompus pouvaient bloquer SIGKILL. Les processus de sommeil interruptibles sont-ils également capables? Si oui, quelle est la différence entre eux?
du
1
Les états S et D sont en fait ininterrompus, simplement parce qu'ils sont trop complexes à programmer dans le noyau et parce que par le passé ils étaient censés n'être que de très courte durée. Bien que le noyau ait évolué pour inclure NFS et d'autres cas qui peuvent prendre beaucoup plus de temps, les attentes de blocage du noyau n'ont malheureusement jamais été supprimées.
harrymc
3
Intéressant. Avez-vous des références à ce sujet? Tout ce que je peux trouver avec Google semble dire que les processus interruptibles ne devraient pas pouvoir ignorer SIGKILL.
du
1
Cela semble simplement contredire tout ce que j'ai lu sur les sommeil interruptibles, et je suis un peu sceptique quant à un comportement non documenté. Par exemple, vérifiez les 2 liens suivants. Suis-je en train de mal comprendre quelque chose? (1) "Dans un sommeil interruptible, le processus pourrait être réveillé pour le traitement des signaux." (2) "Si un signal est généré pour un processus dans cet état, alors l'opération est interrompue et le processus est réveillé par la délivrance d'un signal."
del
1
Un appel système est interruptible ou ne dépend pas uniquement de la façon dont il a été programmé. Une fois que l'on est à l'intérieur du noyau, tout se passe.
harrymc
10

Contexte d'un processus de sommeil

Vous voudrez peut-être jeter un œil à cette publication Unix et Linux.

Plus précisément cette réponse, /unix//a/5648/7453 .

Extrait de ce post

kill -9 (SIGKILL) fonctionne toujours, à condition que vous ayez la permission de tuer le processus. Fondamentalement, soit le processus doit être démarré par vous et ne pas être setuid ou setgid, ou vous devez être root. Il y a une exception: même root ne peut pas envoyer de signal fatal au PID 1 (le processus d'initialisation).

Cependant, kill -9 n'est pas garanti de fonctionner immédiatement. Tous les signaux, y compris SIGKILL, sont délivrés de manière asynchrone: le noyau peut prendre son temps pour les délivrer. Habituellement, la livraison d'un signal prend au plus quelques microsecondes, juste le temps qu'il faut à la cible pour obtenir une tranche de temps. Cependant, si la cible a bloqué le signal, le signal sera mis en file d'attente jusqu'à ce que la cible le débloque.

Normalement, les processus ne peuvent pas bloquer SIGKILL. Mais le code du noyau peut et les processus exécutent le code du noyau lorsqu'ils appellent des appels système. Le code du noyau bloque tous les signaux lorsque l'interruption de l'appel système entraînerait une structure de données mal formée quelque part dans le noyau, ou plus généralement un invariant du noyau violé. Donc, si (en raison d'un bogue ou d'une mauvaise conception) un appel système se bloque indéfiniment, il n'y a effectivement aucun moyen de tuer le processus. (Mais le processus sera tué s'il termine l'appel système.)

...

...

Je suggère fortement de lire le reste de cette réponse!

Tuer un processus bloqué par une ressource (fichier ou réseau)

Voici 2 choses à essayer.

1. Suppression du fichier .pid de yum

Y a-t-il un fichier de verrouillage yum présent? Que se passe-t-il lorsque vous supprimez ce fichier de verrouillage? Je pense que cela pourrait lui permettre de continuer.

rm /var/run/yum.pid

2. Forcer toutes CLOSE_WAITles connexions TCP suspendues fermées

A CLOSE_WAITest décrit comme suit:

CLOSE_WAIT Indique que le serveur a reçu le premier signal FIN du client et que la connexion est en cours de fermeture

Donc, cela signifie essentiellement que son est un état où socket attend que l'application exécute close ()

Un socket peut être indéfiniment dans l'état CLOSE_WAIT jusqu'à ce que l'application le ferme. Des scénarios défectueux seraient comme une fuite de descripteur de fichier, le serveur n'étant pas exécuté close () sur le socket conduisant à l'empilement de sockets close_wait

REMARQUE: extrait du site Web de Technet .

Vous pouvez essayer d'utiliser deux outils pour y parvenir.

Ces outils fonctionnent en simulant l' échange FIN-ACK-RST nécessaire à la fermeture complète d'une connexion TCP.

Killcx fonctionne en créant un faux paquet SYN avec un faux SeqNum, en usurpant l'IP / port client distant et en l'envoyant au serveur. Il va générer un processus enfant qui capturera la réponse du serveur, extraira les 2 valeurs magiques du paquet ACK et les utilisera pour envoyer un paquet RST usurpé. La connexion sera alors fermée.

REMARQUE: extrait du site Web de Killcx .

Utilisation du cutter

Coupe la connexion spécifique entre les deux paires de numéros ip / port fournies.

# cutter ip-address-1 port-1 ip-address-2 port-2
% cutter 200.1.2.3 22 10.10.0.45 32451

Utilisation de Killcx

Coupe les connexions à l'IP et au port distants.

# killcx remote-ip-address:port
% killcx 120.121.122.123:1234

Ressources

slm
la source
La suppression du fichier de verrouillage n'a eu aucun effet.
del
1
C'est sur une machine de production, et malheureusement ces deux outils ont des dépendances que je ne peux pas installer. J'ai essayé /etc/init.d/networking restart et cela n'a rien fait. En fait, je suis maintenant plus intéressé à comprendre pourquoi cela peut se produire (car je ne pensais pas que les processus de sommeil interruptibles pouvaient ignorer SIGKILL) plutôt que comment je peux résoudre ce problème.
du
Le redémarrage du réseau aurait le même effet, donc le blocage des E / S, si c'est en fait ce que le processus attend, se situe ailleurs.
slm
1

Vous pouvez essayer de tuer le processus parent. Utilisez ps pour vérifier:

ps xjf -C yum

Ensuite, kill -9tout processus parent.

terdon
la source
Le processus parent est init (5ème colonne dans ma sortie).
du
1

Il peut être utile de l'attacher au processus avec strace afin de voir s'il est vraiment inactif ou bloqué sur une opération d'E / S. Peut-être fournir d'autres indices sur la question.

strace -pPID

D'après ce que j'ai lu, il n'y a pas d'autre moyen de tuer ce processus que de redémarrer. Si le processus ne consomme pas de temps processeur notable, il est peu probable qu'il ait un impact négatif sur le serveur.


la source
Merci pour la suggestion, mais le processus parent est init (voir la 5e colonne dans ma sortie).
du
Concernant votre réponse révisée, Strace s'attache au processus mais ne produit rien.
du
1

Se pourrait-il qu'il attende un processus enfant? J'adore ps fauxparce que cela vous dira s'il existe ou non des processus enfants et si, que vous devrez peut-être tuer.

Stefan Seidel
la source
Non, ce processus n'a pas de processus enfant.
del