Cómo matar un proceso <defunct> con el padre 1

17

Estoy ejecutando Bacula en una caja de RedHat. De vez en cuando, el almacenamiento daemon bacula-sd deja de funcionar y se vuelve <defunct>.

[root@backup ~]# ps -ef | grep defunct | more
root      4801 29261  0 09:25 pts/5    00:00:00 grep defunct
root      5825     1  0 Oct18 ?        00:00:00 [bacula-sd] <defunct>

Mi pregunta es, ¿cómo puedo matar este proceso? Su padre es 1, que es init, que yo sepa, y no me gustaría matar el proceso init, ¿verdad?

'Normalmente' matar este proceso no funciona:

[root@backup ~]# kill -0 5825
[root@backup ~]# kill -9 5825

¡La ayuda es muy apreciada!

Editar: corriendo

[root@backup ~]# lsof -p 5825

produce el siguiente resultado:

COMMAND    PID USER   FD   TYPE  DEVICE     SIZE    NODE NAME
bacula-sd 5825 root  cwd    DIR   253,0     4096 3801089 /root
bacula-sd 5825 root  rtd    DIR   253,0     4096       2 /
bacula-sd 5825 root  txt    REG   253,0  2110599  368004 /usr/local/sbin/bacula-sd
bacula-sd 5825 root  mem    REG   253,0    75284  389867 /usr/lib/libz.so.1.2.3
bacula-sd 5825 root  mem    REG   253,0    46680 3604521 /lib/libnss_files-2.5.so
bacula-sd 5825 root  mem    REG   253,0   936908  369115 /usr/lib/libstdc++.so.6.0.8
bacula-sd 5825 root  mem    REG   253,0   125736 3606807 /lib/ld-2.5.so
bacula-sd 5825 root  mem    REG   253,0  1602128 3606885 /lib/libc-2.5.so
bacula-sd 5825 root  mem    REG   253,0   208352 3606892 /lib/libm-2.5.so
bacula-sd 5825 root  mem    REG   253,0   125744 3606887 /lib/libpthread-2.5.so
bacula-sd 5825 root  mem    REG   253,0    25940 3604573 /lib/libacl.so.1.1.0
bacula-sd 5825 root  mem    REG   253,0    15972 3604535 /lib/libattr.so.1.1.0
bacula-sd 5825 root  mem    REG   253,0    46548 3606908 /lib/libgcc_s-4.1.2-20080102.so.1
bacula-sd 5825 root  mem    REG   253,0 56422480  366368 /usr/lib/locale/locale-archive
bacula-sd 5825 root    0r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    1r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    2r   CHR     1,3             1545 /dev/null
bacula-sd 5825 root    3u   CHR   9,128             6469 /dev/nst0
bacula-sd 5825 root    4u  IPv4 1023380              TCP backup:bacula-sd (LISTEN)
bacula-sd 5825 root    5u  IPv4 2693268              TCP backup:bacula-sd->backup:53957 (CLOSE_WAIT)
bacula-sd 5825 root    7u  IPv4 3248683              TCP backup:bacula-sd->backup:57629 (CLOSE_WAIT)
bacula-sd 5825 root    8u  IPv4 3250966              TCP backup:bacula-sd->backup:37650 (CLOSE_WAIT)
bacula-sd 5825 root    9u  IPv4 3253908              TCP backup:bacula-sd->backup:37671 (CLOSE_WAIT)
linux process kill bacula andreas-h
fuente
Consulte también unix.stackexchange.com/questions/5642/… y unix.stackexchange.com/questions/11172/…
rogerdpack el

Respuestas:

18

La única forma en que podría eliminar el proceso zombie / difunto, sería matar al padre. Como el padre es init (pid 1), eso también eliminaría su sistema.

Esto prácticamente te deja con dos opciones.

  • Modificar manualmente la tabla de proceso, por ejemplo. cree un proceso ficticio, vincule el proceso difunto como hijo del ficticio y luego elimínelos. Es bastante peligroso, y es posible que deba limpiar manualmente otros recursos del proceso, como semáforos y identificadores de archivos.
  • Reinicia el sistema.

Yo iría con el segundo.

Roy
fuente
2
+1. Sin embargo, tampoco hay prisa por hacerlo, siempre y cuando no aparezcan más procesos zombies, o tu proceso zombie no haya bloqueado 4G de tu RAM. :)
Kyle Smith
1
"Como el padre es init (pid 1), eso también eliminaría su sistema" - No puede matar initya que no tiene un controlador de señal para SIGKILL. Ver man 2 kill.
Cawflands
¿Cómo haces el primero?
skerit
@ Andrew No estoy seguro de que SIGKILL dependa de un controlador de señal en el proceso de destino, pero es cierto que el núcleo típico ignorará un SIGKILL para iniciar. Sin embargo, si te quedas sin formas geniales de desencadenar un pánico en el kernel, creo que encontrarás que en la mayoría de los sistemas Linux un SIGSEGV funcionará bastante bien.
Roy
1
Cabe señalar que uno de initlos trabajos es cosechar procesos zombies, por lo que si espera lo suficiente, initdebe limpiar los procesos zombies. Aunque, la mayoría de los inits deberían configurar el controlador de SIGCHLDser el SIG_IGN que corrige esto.
cyphar
3

Podría intentar reiniciar init:

 # telinit u

De lo contrario, no me preocuparía demasiado. No se está ejecutando y no está tomando ningún recurso y solo está allí para que el núcleo pueda recordarlo.

David Pashley
fuente
1
bueno, me tengo que preocupar. es una máquina de producción que ejecuta servicios de respaldo (bacula) y voip (asterisco). siempre y cuando el proceso de Bacula-sd desaparecida está ahí, Bacula parece que no puede acceder a la unidad de cinta ...
Andreas-h
No debería tener ningún archivo abierto. Ejecute lsof -p 5825 y verifique.
David Pashley
Bueno, parece que hay muchas cosas abiertas ... ver arriba. ¿Alguna idea de lo que puedo hacer? Nunca he usado lsof ...
andreas-h
1
Sí, tu zombie tiene / dev / nst0 abierto. Un reinicio del sistema es probablemente la mejor apuesta en este momento.
Kyle Smith
55
Sí, reiniciar parece ser la respuesta predominante. Siempre siento que he fallado cuando tengo que reiniciar un servidor. :(
David Pashley
3

Compruebe si hubo pánico en el núcleo, 

# dmesg |tail

Compruebe si el proceso está en suspensión inactiva "D", donde está en modo kernel para alguna llamada al sistema que aún no ha regresado (ya sea kernel oops, o alguna otra razón) http://www.nabble.com/What-causes-an -procesador indescifrable - td20645581.html

Pausado hasta nuevo aviso.
fuente
formato molesto
asdmin
en realidad, no ha habido pánico en el núcleo. proceso está en estado 'Z' - un zombie ...
andreas-h
3

Si un zombie tiene init como padre, entonces init ha dejado de funcionar correctamente. Una de las funciones de init es limpiar zombies. Si no lo hace, nadie más lo hará. Entonces, la única solución es reiniciar. Si init está roto, entonces un reinicio puede fallar, por lo que cerraría los servicios importantes, sincronizaría el sistema de archivos y luego presionaría el botón de encendido.

MarkR
fuente
Estoy de acuerdo en que init no funciona correctamente. Ver también: upstarty systemd.
Mikko Rantalainen
2

Mantengamos el pánico bajo, ¿de acuerdo? Un proceso "difunto" o "zombie" no es un proceso . Es simplemente una entrada en la tabla de proceso, con un código de salida guardado. Por lo tanto, un zombie no tiene recursos, no requiere ciclos de CPU y no usa memoria, ya que no es un proceso . No te pongas todo raro y con picazón tratando de "matar" los procesos de zombies. Al igual que sus homónimos, no pueden ser asesinados, ya que ya están muertos. Pero a diferencia del tipo que come el cerebro, no dañan absolutamente a nadie y no morderán otros procesos.

No dejes que los procesos zombies te coman el cerebro. Sólo ingoralos.

Osito de peluche
fuente
11
Sí, esa es la teoría. Lamentablemente, no siempre es cierto. Un proceso difunto a veces se aferrará a los recursos del sistema, como andreash ha documentado claramente.
Roy
55
En su caso, según el resultado de lsof, el proceso zombie se está comiendo el cerebro de / dev / nst0. Necesita esos cerebros para continuar con las operaciones de respaldo.
Kyle Smith
2
Un administrador del sistema que pasa su carrera haciendo caso omiso de los procesos de Zombie eventualmente se despertará en medio de la noche con su vida siendo absorbida por ellos. Un zombi es, en mi experiencia, indicativo de algo mal. Escribo esto incluso cuando un niño zombie tiene una interacción extraña con su padre, y el padre está girando mi CPU. No sé de quién es la culpa, pero el punto es que los zombis son feos e ignorarlos algún día vendrá a atormentarte. ... Un día ... cuando duermes tranquilamente ... en medio de la noche ... después de un frío día de otoño ...
Mike S
@MikeS ¡Me reí mucho de tu comentario!
Paul Calabro
@MikeS tiene razón. Tengo ssh-agent desaparecido y ssh ni git no se pueden ejecutar correctamente. solo reiniciar puede ayudar. (mismo arreglo que Windows tiene ... jaja)
John Tribe
0

Parece que tienes un proceso huérfano. Por lo que sé, la única forma de matarlos sería reiniciar la caja. Esto sucede en mis servidores ESX (que son Linux bajo el capó) de vez en cuando y un reinicio del host es la solución (desde el soporte de VMware).

Soy un chico de Windows, así que tómalo por lo que vale.

mrdenny
fuente
desafortunadamente, reiniciar no es una opción real. es una máquina de producción también ejecuta los servicios de VoIP, así que no puedo reiniciarlo en horario de oficina ...
Andreas-h
1
entonces, podrías reiniciarlo después del horario de oficina, ¿verdad?
warren