No se puede matar un proceso de sueño

13

Parece que no puedo matar -9 un proceso que está en un estado de suspensión interrumpible (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

¿Cómo es esto posible? ¿Hay alguna forma de matar el proceso sin reiniciar?

BOUNTY: Estoy realmente más interesado en una explicación de cómo es posible que esto ocurra.

ACTUALIZACIÓN: Esta es la salida de lsof:

[root @ jupiter ~] # lsof -p 16790
COMANDO PID USUARIO FD TIPO DISPOSITIVO TAMAÑO / APAGADO NODO NOMBRE
yum 16790 root cwd DIR 1166,56842 4096 16886249 / home / del
yum 16790 raíz rtd DIR 253,0 4096 2 /
yum 16790 root txt REG 253,0 8304 336177337 / usr / bin / python
yum 16790 root mem REG 253,0 144776 346128569 /lib64/ld-2.5.so
yum 16790 root mem REG 253,0 1718232 346128573 /lib64/libc-2.5.so
yum 16790 root mem REG 253,0 23360 346128599 /lib64/libdl-2.5.so
yum 16790 root mem REG 253,0 145872 346128584 /lib64/libpthread-2.5.so
yum 16790 root mem REG 253,0 615136 346128602 /lib64/libm-2.5.so
yum 16790 root mem REG 253,0 1244792 336171087 /usr/lib64/libpython2.4.so.1.0
yum 16790 root mem REG 253,0 95464 346128744 /lib64/libselinux.so.1
yum 16790 root mem REG 253,0 53448 346128750 /lib64/librt-2.5.so
yum 16790 root mem REG 253,0 13960 336187564 /usr/lib64/libplds4.so
yum 16790 root mem REG 253,0 58400 346128752 /lib64/libgcc_s-4.1.2-20080825.so.1
yum 16790 root mem REG 253,0 78384 336173796 /usr/lib64/libelf-0.137.so
yum 16790 root mem REG 253,0 1139672 336187570 /usr/lib64/librpmdb-4.4.so
yum 16790 root mem REG 253,0 407792 336187568 /usr/lib64/librpmio-4.4.so
yum 16790 root mem REG 253,0 233144 336171420 /usr/lib64/libnspr4.so
yum 16790 root mem REG 253,0 375656 336187569 /usr/lib64/libsqlite3.so.0.8.6
yum 16790 root mem REG 253,0 17992 336187563 /usr/lib64/libplc4.so
yum 16790 root mem REG 253,0 386784 336187571 /usr/lib64/librpm-4.4.so
yum 16790 root mem REG 253,0 154776 336170228 /usr/lib64/librpmbuild-4.4.so
yum 16790 root mem REG 253,0 647608 346128759 /lib64/libglib-2.0.so.0.1200.3
yum 16790 root mem REG 253,0 1297136 336176959 /usr/lib64/libxml2.so.2.6.26
yum 16790 root mem REG 253,0 15584 346128756 /lib64/libtermcap.so.2.0.8
yum 16790 root mem REG 253,0 1234328 336187566 /usr/lib64/libnss3.so
yum 16790 root mem REG 253,0 18152 346128670 /lib64/libutil-2.5.so
yum 16790 root mem REG 253,0 34240 336177071 /usr/lib64/libpopt.so.0.0.0
yum 16790 root mem REG 253,0 67792 336187567 /usr/lib64/libbz2.so.1.0.3
yum 16790 root mem REG 253,0 143144 346128763 /lib64/libexpat.so.0.5.0
yum 16790 root mem REG 253,0 56434416 336184082 / usr / lib / locale / locale-archive
yum 16790 root mem REG 253,0 132656 336560181 /usr/lib64/python2.4/site-packages/rpm/_rpmmodule.so
yum 16790 root mem REG 253,0 154016 336187565 /usr/lib64/libnssutil3.so
yum 16790 root mem REG 253,0 96885 345638632 /usr/local/greenplum-loaders-3.3.0.0-build-3/lib/libz.so.1.2.3
yum 16790 root mem REG 253,0 247496 346128741 /lib64/libsepol.so.1
yum 16790 root mem REG 253,0 369144 336168883 /usr/lib64/libsoftokn3.so
yum 16790 root mem REG 253,0 312336 336178453 /usr/lib64/libfreebl3.so
yum 16790 root mem REG 253,0 20240 336530067 /usr/lib64/python2.4/lib-dynload/timemodule.so
yum 16790 root mem REG 253,0 25048 336529953 /usr/lib64/python2.4/lib-dynload/stropmodule.so
yum 16790 root mem REG 253,0 18984 336530051 /usr/lib64/python2.4/lib-dynload/cStringIO.so
yum 16790 root mem REG 253,0 21816 336529943 /usr/lib64/python2.4/lib-dynload/collectionsmodule.so
yum 16790 root mem REG 253,0 52152 336530044 /usr/lib64/python2.4/lib-dynload/_socketmodule.so
yum 16790 root mem REG 253,0 17200 336530045 /usr/lib64/python2.4/lib-dynload/_ssl.so
yum 16790 root mem REG 253,0 315080 346128749 /lib64/libssl.so.0.9.8e
yum 16790 root mem REG 253,0 1366912 346128748 /lib64/libcrypto.so.0.9.8e
yum 16790 root mem REG 253,0 190976 336187552 /usr/lib64/libgssapi_krb5.so.2.2
yum 16790 root mem REG 253,0 613928 336184245 /usr/lib64/libkrb5.so.3.3
yum 16790 root mem REG 253,0 11760 346128747 /lib64/libcom_err.so.2.1
yum 16790 root mem REG 253,0 153720 336181723 /usr/lib64/libk5crypto.so.3.1
yum 16790 root mem REG 253,0 35984 336177832 /usr/lib64/libkrb5support.so.0.1
yum 16790 root mem REG 253,0 9472 346128681 /lib64/libkeyutils-1.2.so
yum 16790 root mem REG 253,0 92816 346128730 /lib64/libresolv-2.5.so
yum 16790 root mem REG 253,0 75384 336530050 /usr/lib64/python2.4/lib-dynload/cPickle.so
yum 16790 root mem REG 253,0 23736 336530064 /usr/lib64/python2.4/lib-dynload/structmodule.so
yum 16790 root mem REG 253,0 27336 336528958 /usr/lib64/python2.4/lib-dynload/operator.so
yum 16790 root mem REG 253,0 21520 336529958 /usr/lib64/python2.4/lib-dynload/zlibmodule.so
yum 16790 root mem REG 253,0 37944 336528952 /usr/lib64/python2.4/lib-dynload/itertoolsmodule.so
yum 16790 root mem REG 253,0 21528 336528929 /usr/lib64/python2.4/lib-dynload/_localemodule.so
yum 16790 root mem REG 253,0 21208 336529939 /usr/lib64/python2.4/lib-dynload/binascii.so
yum 16790 root mem REG 253,0 12080 336530062 /usr/lib64/python2.4/lib-dynload/shamodule.so
yum 16790 root mem REG 253,0 13168 336530058 /usr/lib64/python2.4/lib-dynload/md5module.so
yum 16790 root mem REG 253,0 18000 336529947 /usr/lib64/python2.4/lib-dynload/mathmodule.so
yum 16790 root mem REG 253,0 12504 336529934 /usr/lib64/python2.4/lib-dynload/_randommodule.so
yum 16790 root mem REG 253,0 15320 336528948 /usr/lib64/python2.4/lib-dynload/fcntlmodule.so
yum 16790 root mem REG 253,0 32816 336530049 /usr/lib64/python2.4/lib-dynload/bz2.so
yum 16790 root mem REG 253,0 8608 336529946 /usr/lib64/python2.4/lib-dynload/grpmodule.so
yum 16790 root mem REG 253,0 38696 336529819 /usr/lib64/python2.4/site-packages/cElementTree.so
yum 16790 root mem REG 253,0 42672 336530047 /usr/lib64/python2.4/lib-dynload/arraymodule.so
yum 16790 root mem REG 253,0 9368 336528915 /usr/lib64/python2.4/lib-dynload/_bisect.so
yum 16790 root mem REG 253,0 74992 336529944 /usr/lib64/python2.4/lib-dynload/datetime.so
yum 16790 root mem REG 253,0 372912 336560510 /usr/lib64/python2.4/site-packages/M2Crypto/__m2crypto.so
yum 16790 root mem REG 253,0 7120 336529937 /usr/lib64/python2.4/lib-dynload/_weakref.so
yum 16790 root mem REG 253,0 17496 336528966 /usr/lib64/python2.4/lib-dynload/selectmodule.so
yum 16790 root mem REG 253,0 46448 336528961 /usr/lib64/python2.4/lib-dynload/pyexpat.so
yum 16790 root mem REG 253,0 33896 336529820 /usr/lib64/python2.4/site-packages/_sqlite.so
yum 16790 root mem REG 253,0 41784 336530075 /usr/lib64/python2.4/site-packages/_sqlitecache.so
yum 16790 root mem REG 253,0 25104 336530066 /usr/lib64/python2.4/lib-dynload/termios.so
yum 16790 root mem REG 253,0 7280 336530065 /usr/lib64/python2.4/lib-dynload/syslog.so
yum 16790 root mem REG 253,0 25464 336265457 /usr/lib64/gconv/gconv-modules.cache
yum 16790 root mem REG 253,0 66544 336528926 /usr/lib64/python2.4/lib-dynload/_cursesmodule.so
yum 16790 root mem REG 253,0 380336 336181932 /usr/lib64/libncurses.so.5.5
yum 16790 root mem REG 253,0 405880 336529957 /usr/lib64/python2.4/lib-dynload/unicodedata.so
yum 16790 root mem REG 253,0 24576 236520047 /var/lib/rpm/__db.001
yum 16790 root mem REG 253,0 53880 346128424 /lib64/libnss_files-2.5.so
yum 16790 root mem REG 253,0 23736 346128408 /lib64/libnss_dns-2.5.so
yum 16790 root mem REG 253,0 1318912 236520050 /var/lib/rpm/__db.002
yum 16790 root mem REG 253,0 663552 236520051 /var/lib/rpm/__db.003
yum 16790 root mem REG 253,0 769074 336174965 /usr/share/locale/en_US/LC_MESSAGES/redhat-dist.mo
yum 16790 raíz 0u CHR 136,8 0t0 10 / dev / pts / 8 (eliminado)
yum 16790 raíz 1u CHR 136,8 0t0 10 / dev / pts / 8 (eliminado)
yum 16790 raíz 2u CHR 136,8 0t0 10 / dev / pts / 8 (eliminado)
yum 16790 raíz 3u unix 0xffff8104388d2e40 0t0 4675113 zócalo
yum 16790 raíz 4w REG 253,0 0 236522326 /var/log/yum.log
yum 16790 raíz 5u REG 253,0 605184 236520025 /var/cache/yum/WANdisco-dev/primary.xml.gz.sqlite
yum 16790 raíz 6u REG 253,0 20480 236524002 /var/cache/yum/addons/primary.sqlite.old.tmp (eliminado)
yum 16790 root 7u REG 253,0 12578816 236519970 /var/cache/yum/base/primary.xml.gz.sqlite.old.tmp (eliminado)
yum 16790 raíz 8u REG 253,0 17972224 236523993 /var/cache/yum/epel/317109b44f1b0b40d910dc60c9080e62c7f4b16a-primary.sqlite.old.tmp (eliminado)
yum 16790 raíz 9u REG 253,0 967680 236524055 /var/cache/yum/extras/primary.sqlite.old.tmp (eliminado)
yum 16790 raíz 10u REG 253,0 459776 246415366 /var/cache/yum/pgdg92/primary.sqlite.old.tmp (eliminado)
yum 16790 raíz 11u REG 253,0 4927488 236524060 /var/cache/yum/updates/primary.sqlite.old.tmp (eliminado)
yum 16790 root 12r REG 253,0 65204224 236519434 / var / lib / rpm / Paquetes
yum 16790 root 13r REG 253,0 45056 236519438 / var / lib / rpm / Nombre
yum 16790 raíz 14u IPv4 4675317 0t0 TCP jupiter.example.com:33597->riksun.riken.go.jp:http (ESTABLECIDO)
yum 16790 raíz 15u IPv4 4675939 0t0 TCP jupiter.example.com:52708->freedom.itsc.cuhk.edu.hk:http (CLOSE_WAIT)
yum 16790 root 16r REG 253,0 65204224 236519434 / var / lib / rpm / Paquetes
yum 16790 root 17r REG 253,0 45056 236519438 / var / lib / rpm / Nombre
yum 16790 root 18r REG 253,0 12288 236519440 / var / lib / rpm / Pubkeys
yum 16790 raíz 20r FIFO 0,6 0t0 4676024 tubería
yum 16790 raíz 24w FIFO 0,6 0t0 4676024 tubería

linux centos process kill del
fuente

Mata los otros procesos que manipulan el mismo bloqueo y probablemente se desatascará.

David Schwartz

@David: no puedo eliminar ninguno de los procesos de yum en la lista de procesos anterior; Todos ellos tienen el mismo problema.

del

Eliminé las líneas adicionales porque no agregaban más información y dificultaban la lectura de su publicación.

terdon el

@slm - lsof muestra los sockets TCP a riksun.riken.go.jp:80 (ESTABLECIDO) y freedom.itsc.cuhk.edu.hk:80 (CLOSE_WAIT). Supongo que podría ser eso?

del

@slm: consulte mi pregunta actualizada.

del

18

Un proceso en estado S o D suele estar en una llamada de sistema de bloqueo, como leer o escribir en un archivo o en la red, esperando que finalice un programa llamado o mientras espera semáforos u otras primitivas de sincronización. Entrará en estado de suspensión mientras espera.

No puede "despertarlo", solo continuará cuando los datos / recursos que está esperando estén disponibles. Todo esto es normal y esperado, y solo es un problema al intentar matarlo.

Puede intentar y usar strace -p pidpara averiguar qué llamada al sistema está ocurriendo actualmente para el proceso pid.

De wikipedia :

Un estado de suspensión ininterrumpible es un estado de suspensión que no manejará una señal de inmediato. Solo se activará como resultado de la disponibilidad de un recurso esperado o después de que se agote el tiempo de espera durante esa espera (si se especifica cuando se pone a dormir). Lo utilizan principalmente los controladores de dispositivos que esperan disco o red IO (entrada / salida). Cuando el proceso duerme ininterrumpidamente, las señales acumuladas durante el sueño se notarán cuando el proceso regrese de la llamada o trampa del sistema.

Un proceso bloqueado en una llamada del sistema está en suspensión ininterrumpida, que como su nombre lo dice, es realmente ininterrumpible incluso por root.

Normalmente, los procesos no pueden bloquear SIGKILL. Pero el código del núcleo puede, y los procesos ejecutan el código del núcleo cuando llaman a las llamadas del sistema, durante el cual el código del núcleo bloquea todas las señales. Por lo tanto, si una llamada al sistema se bloquea indefinidamente, es posible que no haya forma de matar el proceso. SIGKILL solo tendrá efecto cuando el proceso complete la llamada al sistema.

harrymc
fuente

2

Pensé que solo los procesos de suspensión ininterrumpida podían bloquear SIGKILL. ¿Son capaces también los procesos de sueño interrumpibles? Si es así, ¿cuál es la diferencia entre ellos?

del

1

Los estados S y D son en efecto ininterrumpibles, simplemente porque son demasiado complejos para programar en el núcleo y porque en el pasado se suponía que eran de muy corta duración. Aunque el núcleo ha evolucionado para incluir NFS y otros casos que pueden tomar mucho más tiempo, lamentablemente nunca se abolieron las esperas de bloqueo del núcleo.

harrymc

3

Interesante. ¿Tienes alguna referencia para esto? Todo lo que puedo encontrar con Google parece decir que los procesos interrumpibles no deberían poder ignorar SIGKILL.

del

1

Simplemente parece contradecir todo lo que he leído sobre los sueños interrumpibles, y estoy un poco escéptico de haber tropezado con algún comportamiento indocumentado. Por ejemplo, consulte los siguientes 2 enlaces. ¿Estoy malinterpretando algo? (1) "En un sueño interrumpible, el proceso podría despertarse para el procesamiento de señales". (2) "Si se genera una señal para un proceso en este estado, la operación se interrumpe y el proceso se despierta por la entrega de una señal".

del

1

Una llamada al sistema es interrumpible o no depende solo de cómo se programó. Una vez que uno está dentro del núcleo, todo se va.

harrymc

10

Antecedentes sobre un proceso de sueño

Es posible que desee echar un vistazo a esta publicación de Unix y Linux.

/unix/5642/what-if-kill-9-does-not-work

Específicamente esta respuesta, /unix//a/5648/7453 .

Extracto de esa publicación

kill -9 (SIGKILL) siempre funciona, siempre que tenga permiso para eliminar el proceso. Básicamente, el proceso debe ser iniciado por usted y no ser setuid o setgid, o debe ser root. Hay una excepción: incluso el root no puede enviar una señal fatal al PID 1 (el proceso de inicio).

Sin embargo, kill -9 no está garantizado para funcionar de inmediato. Todas las señales, incluida SIGKILL, se entregan de forma asíncrona: el núcleo puede tardar en entregarlas. Por lo general, la entrega de una señal lleva como máximo unos pocos microsegundos, justo el tiempo que le toma al objetivo obtener un segmento de tiempo. Sin embargo, si el objetivo ha bloqueado la señal, la señal se pondrá en cola hasta que el objetivo la desbloquee.

Normalmente, los procesos no pueden bloquear SIGKILL. Pero el código del núcleo puede y los procesos ejecutan el código del núcleo cuando llaman a las llamadas del sistema. El código del kernel bloquea todas las señales cuando la interrupción de la llamada del sistema daría como resultado una estructura de datos mal formada en algún lugar del kernel, o más generalmente en la violación de algún invariante del kernel. Entonces, si (debido a un error o diseño incorrecto) una llamada del sistema se bloquea indefinidamente, es posible que no haya forma de matar el proceso. (Pero el proceso finalizará si alguna vez completa la llamada al sistema).

...

...

¡Recomiendo leer el resto de esa respuesta!

Matar un proceso que está bloqueado por un recurso (archivo o red)

Aquí hay 2 cosas para probar.

1. Eliminando el archivo .pid de yum

¿Hay un archivo de bloqueo yum presente? ¿Qué sucede cuando eliminas ese archivo de bloqueo? Creo que eso podría permitir que continúe.

rm /var/run/yum.pid

2. Forzar el `CLOSE_WAIT`cierre de las conexiones TCP colgantes

A CLOSE_WAITse describe como sigue:

CLOSE_WAIT Indica que el servidor ha recibido la primera señal FIN del cliente y que la conexión está en proceso de cierre

Entonces, esto significa esencialmente que es un estado en el que el socket está esperando que la aplicación se ejecute close ()

Un socket puede estar en estado CLOSE_WAIT indefinidamente hasta que la aplicación lo cierre. Los escenarios defectuosos serían como una fuga del descriptor de archivo, el servidor no se ejecuta close () en el socket que conduce a la acumulación de sockets close_wait

NOTA: Extracto del sitio web de technet .

Hay 2 herramientas que puede intentar usar para lograr esto.

Estas herramientas funcionan simulando el intercambio FIN-ACK-RST que es necesario para que una conexión TCP se cierre por completo.

Killcx funciona creando un paquete SYN falso con un SeqNum falso, falsificando el IP / puerto del cliente remoto y enviándolo al servidor. Bifurcará un proceso secundario que capturará la respuesta del servidor, extraerá los 2 valores mágicos del paquete ACK y los usará para enviar un paquete RST falsificado. La conexión se cerrará.

NOTA: Extracto del sitio web de Killcx .

Usando cortador

Corta la conexión específica entre los dos pares de números de ip / puerto dados.

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

Usando Killcx

Corta conexiones a ip y puerto remotos.

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

Recursos

serverfault - Cómo cerrar a la fuerza un socket a tiempo de espera

slm
fuente

Eliminar el archivo de bloqueo no tuvo ningún efecto.

del

1

Esto está en una máquina de producción, y desafortunadamente estas dos herramientas tienen dependencias que no puedo instalar. Intenté /etc/init.d/networking restart y no hizo nada. En realidad, ahora estoy más interesado en comprender por qué esto puede suceder (ya que no pensé que los procesos de sueño interrumpibles pudieran ignorar SIGKILL) en lugar de cómo puedo solucionar este problema.

del

Reiniciar la red tendría el mismo efecto, por lo que el bloqueo de E / S, si eso es lo que el proceso está esperando, se encuentra en otra parte.

slm

1

Podrías intentar matar el proceso padre. Use ps para verificar:

ps xjf -C yum

Entonces kill -9cualquier padre procesa.

terdon
fuente

El proceso padre es init (quinta columna en mi salida).

del

1

Puede valer la pena adjuntar al proceso con strace para ver si está realmente inactivo o atascado en una operación de E / S. Puede proporcionar más pistas sobre el tema, tal vez.

strace -pPID

Por lo que he leído, no hay forma de matar este proceso que no sea reiniciar. Si el proceso no consume un tiempo de CPU notable, es poco probable que genere un impacto negativo en el servidor.

fuente

Gracias por la sugerencia, pero el proceso principal es init (ver la quinta columna en mi salida).

del

Re su respuesta revisada, strace se adjunta al proceso pero no genera nada.

del

1

¿Podría ser que está esperando un proceso secundario? Me encanta ps fauxporque te dirá si hay procesos secundarios o no, y si es necesario matar.

Stefan Seidel
fuente

No, este proceso no tiene ningún proceso hijo.

del