Matar un proceso definitivamente

[Reinoso G.]

Hola, feliz año a todos.

El xmms se ha quedado patitieso y le he mandado un kill con intención de
matarlo:

killall xmms

Como veo que no se muere, elijo un método más contundente:

killall -9 xmms
(varias veces seguidas)

No obstante sigo viendo la ventana en la X, y esta se redibuja al
minimizarla y maximizarla, asi que el proceso xmms no está detenido. Echo
un vistazo a ps -aux:
reinoso 2640 0.3 3.4 34888 17892 ? D 12:53 0:04 xmms
/mio/mp3 /cdrom /cdrom2 /cdrom3
reinoso 2641 0.0 0.0 0 0 ? Z 12:53 0:00 [xmms]
<defunct>
reinoso 2644 0.0 3.4 34888 17892 ? D 12:54 0:00 xmms
/mio/mp3 /cdrom /cdrom2 /cdrom3


El proceso principal está KO, zombi. Pero otros dos procesos siguen vivos.
En otras ocasiones con speakfreely me ha pasado que el proceso se queda
zombi hasta reiniciar el sistema, consumiendo toda la CPU según top (yo
pensaba que los procesos zombi no consumían resursos).
En este caso xmms ha muerto unos 3 minutos después, desapareciendo sus
ventanas.



¿Hay alguna forma de decirle al kernel "sácame este proceso de la tabla de
procesos, quítalo de la memoria, no le pases el control y elimina todos
sus restos PERO AHORA MISMO, YA"?


Saludos y gracias.

[Gorka Olaizola]

Post by Reinoso G.
reinoso 2640 0.3 3.4 34888 17892 ? D 12:53 0:04 xmms
/mio/mp3 /cdrom /cdrom2 /cdrom3

Lo que te ha pasado es que el xmms se ha quedado pillado en una función del
núcleo y hasta que no acabe esa función no se puede matar. Que yo sepa, a
parte de esperar, no se puede hacer nada cuando un programa se queda en ese
estado. Quizá con alguna de las teclas mágicas del núcleo se pueda
matar definitivamente, aunque yo nunca lo he probado.

[Raúl (Ridiculum)]

Post by Reinoso G.
No obstante sigo viendo la ventana en la X, y esta se redibuja al
minimizarla y maximizarla, asi que el proceso xmms no está detenido. Echo
reinoso 2640 0.3 3.4 34888 17892 ? D 12:53 0:04 xmms
/mio/mp3 /cdrom /cdrom2 /cdrom3
reinoso 2641 0.0 0.0 0 0 ? Z 12:53 0:00 [xmms]
<defunct>
reinoso 2644 0.0 3.4 34888 17892 ? D 12:54 0:00 xmms
/mio/mp3 /cdrom /cdrom2 /cdrom3

Ese estado D no es nada bueno: se supone que eso significa que esta en
un estado ininterrumpible (tipicamente esperando por E/S)

Post by Reinoso G.
¿Hay alguna forma de decirle al kernel "sácame este proceso de la tabla de
procesos, quítalo de la memoria, no le pases el control y elimina todos
sus restos PERO AHORA MISMO, YA"?

A mi no me suena nada mas que SIGKILL

[Iñaki Arenaza]

Post by Reinoso G.
¿Hay alguna forma de decirle al kernel "sácame este proceso de
la tabla de procesos, quítalo de la memoria, no le pases el
control y elimina todos sus restos PERO AHORA MISMO, YA"?

Raúl> A mi no me suena nada mas que SIGKILL

Solo que SIGKILL (y el resto de señales) no se entregan al proceso
mientras este está en modo nucleo. Y como estando en espera de
entradas/salidas (flag 'D' en el listado anterior) se esta en modo
nucleo, SIGKILL no funcionara. Es decir, salvo reinicio de por medio
(o que el proceso salga del estado 'D' por medios externos), no hay
nada que hacer.

Saludos. Iñaki.

- --
Get PGP/GPG Keys at http://www.escomposlinux.org/iarenaza/pgpkey.php
I use free software / Yo uso software libre

[Matías Costa]

Post by Iñaki Arenaza
Solo que SIGKILL (y el resto de señales) no se entregan al proceso
mientras este está en modo nucleo. Y como estando en espera de
entradas/salidas (flag 'D' en el listado anterior) se esta en modo
nucleo, SIGKILL no funcionara. Es decir, salvo reinicio de por medio
(o que el proceso salga del estado 'D' por medios externos), no hay
nada que hacer.

Aunque lo que dices es perfectamente logico, mi experiencia me dice que a un
kill -9 no sobrevive nada. El caso de los procesos zombies es especial, y
que tienes que matar al padre. Joder parece una pelicula de miedo, estos de
unix/linux tienen tela para poner nombres a las cosas, demonios, zombies y
duendes (gnome).

Un "ps ax -forest" te ayudara a identificar el padre, en mi ordenador el
padre es kdeinit, por lo que si te cargo al padre me cargo todo KDE. Para
solucionar esto me he hecho un pequeño script para que el padre sea bash y
al morir pase a ser hijo de init. Valla, este init es el unico proceso que
no puedes matar.

#!/bin/bash
nohup /usr/bin/xmms 2>&1 > /dev/null &

Y despues un enlace tipo "aplicaciones no KDE" para el script.

En definitiva, para procesos reveldes "xkill"+"kill -9". Y ante una
autentica revolución un "magic sysrq".

Un amigo me pregunto: ¿Con linux que puedes hacer?. Y le respondi: ¡puedes
hacer todo lo que sepas!

[Iñaki Arenaza]

Matías> Aunque lo que dices es perfectamente logico, mi
Matías> experiencia me dice que a un kill -9 no sobrevive nada. El

Tu experiencia no es completa entonces :). Hay casos en los que un
kill -9 _no_ funciona. Por la razon que he mencionado antes.

Si un proceso hace una llamada al sistema y una vez dentro de esta se
queda bloqueado dentro del nucleo (las llamadas del sistema se
ejecutan dentro del nucleo), el nucleo no le envia las señales y el
proceso no las recibe. Mientras este dentro del nucleo no le llegaran,
y por tanto, no les podra hacer caso. Da igual que sea SIGTERM
(ignorable como la mayoria), SIGKILL o SIGSTOP (las dos unicas que no
se pueden ignorar).

Por tanto, mientras el proceso no recibe las señales (esto es, esté
bloqueado dentro del nucleo), no se puede morir. Hace falta primero
que salga de ese estado de bloqueo y finalice la llamada al sistema y
abandone el nucleo. Si eso no se produce (y a veces pasa), el proceso
no se puede morir, por mucho kill -9 que uses.

Saludos. Iñaki.

- --
Get PGP/GPG Keys at http://www.escomposlinux.org/iarenaza/pgpkey.php
I use free software / Yo uso software libre

[bqp]

El Sun, 11 Jan 2004 23:50:29 +0100, Iñaki Arenaza <***@eb2ebu.ampr.org> disidio iscribir:

Guenas

Post by Iñaki Arenaza
Tu experiencia no es completa entonces :). Hay casos en los que un
kill -9 _no_ funciona. Por la razon que he mencionado antes.

A mí ese caso se me ha dado con frecuencia cuando algo fallaba al hacer
backup a una unidad de cinta IDE (con una similar en SCSI no me ha
ocurrido), y obligaba a reiniciar porque dejaba pillado el dispositivo.
Me ocurría por algo bastante chorra: la pestaña de protección contra
escritura estaba en el lugar equivocado (cintas tipo Travan).

Saludines
- --
bqp <***@agujero-negro.escomposlinux.org> Linux Reg. User #66054
** Quita el agujero negro de mi dirección **
Servicio de news de ecolnet: escribe a ***@escomposlinux.org
Servidor de irc: irc.escomposlinux.org

[José G. Juanino]

Post by bqp
Guenas

Post by Iñaki Arenaza
Tu experiencia no es completa entonces :). Hay casos en los que un
kill -9 _no_ funciona. Por la razon que he mencionado antes.

A mí ese caso se me ha dado con frecuencia cuando algo fallaba al hacer
backup a una unidad de cinta IDE (con una similar en SCSI no me ha
ocurrido), y obligaba a reiniciar porque dejaba pillado el dispositivo.
Me ocurría por algo bastante chorra: la pestaña de protección contra
escritura estaba en el lugar equivocado (cintas tipo Travan).

Otro caso: insertas un módulo en el kernel y por cualquier motivo el
sistema no puede hacerlo, pero se queda pendiente de ello y no te
devuelve el prompt a la línea de comandos (ves en el gkrellm que el
consumo de CPU es 99% de llamadas al sistema... en color naranja). Si
intentas matar con un kill -9 el proceso modprobe correspondiente, ves
que no puedes. O esperas a que termine, o rebotas la máquina o le pegas
un botonazo :)

Saludos

Juanino

[Matías Costa]

Tenéis razón este tipo de cosas nunca me han pasado. En los años que llevo
usando linux nunca me había encontrado con un proceso que no pudiera matar.

[Juanjo Álvarez]

El Sun, 11 Jan 2004 23:50:29 +0100'

Post by Iñaki Arenaza
Matías> Aunque lo que dices es perfectamente logico, mi
Matías> experiencia me dice que a un kill -9 no sobrevive nada. El
Tu experiencia no es completa entonces :). Hay casos en los que un
kill -9 _no_ funciona. Por la razon que he mencionado antes.

Cierto lo que dices Iñaki (yo también lo he vivido) sin embargo con el
parche kpreempt (de serie en los kernels 2.6) como efecto lateral, y
salvo que el kernel esté en una zona marcada como "no-preemptible" eso
pasa mucho menos.