Comment tuer un processus <defunct> avec le parent 1

17

J'utilise Bacula sur une boîte RedHat. De temps en temps, le démon de stockage bacula-sd cesse de fonctionner et devient <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>

Ma question est, comment puis-je tuer ce processus? Son parent est 1, qui est init, pour autant que je sache, et je ne voudrais pas tuer le processus d'initialisation, n'est-ce pas?

Tuer ce processus normalement ne fonctionne pas:

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

L'aide est grandement appréciée!

Modifier: en cours d'exécution

[root@backup ~]# lsof -p 5825

produit la sortie suivante:

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)

— andreas-h
source

Voir aussi unix.stackexchange.com/questions/5642/… et unix.stackexchange.com/questions/11172/…

— rogerdpack

18

La seule façon de supprimer le processus zombie / défunt serait de tuer le parent. Puisque le parent est init (pid 1), cela détruirait également votre système.

Cela vous laisse à peu près deux options.

Modifiez manuellement la table de processus, par exemple. créer un processus fictif, lier le processus défunt en tant qu'enfant du mannequin, puis les tuer. Assez dangereux et vous devrez peut-être nettoyer manuellement d'autres ressources de processus telles que les sémaphores et les descripteurs de fichiers.
Redémarrez le système.

J'irais avec le second.

— Roy
source

2

+1. Cependant, il n'y a pas de précipitation à faire non plus, tant que plus de processus zombies n'apparaissent pas ou que votre processus zombie n'a pas verrouillé la 4G de votre RAM. :)

— Kyle Smith

1

"Puisque le parent est init (pid 1), cela détruirait également votre système" - Vous ne pouvez pas tuer initcar il n'a pas de gestionnaire de signal pour SIGKILL. Tu vois man 2 kill.

— Cawflands

Comment faites-vous le premier?

— skerit

@AndrewH Je ne suis pas sûr que SIGKILL dépende d'un gestionnaire de signal dans le processus cible, mais il est vrai que le noyau typique ignorera un SIGKILL à init. Cependant, si vous manquez de moyens plus cool pour déclencher une panique du noyau, je pense que vous constaterez que sur la plupart des systèmes Linux, un SIGSEGV fonctionnera très bien.

— Roy

1

Il convient de noter que l'un des initemplois consiste à récolter des processus zombies, donc si vous attendez assez longtemps, initnettoyez les processus zombies. Cependant, la plupart des inits devraient définir le gestionnaire de SIGCHLDpour SIG_IGN résoudre ce problème.

— cyphar

3

Vous pouvez essayer de redémarrer init:

 # telinit u

Sinon, je ne m'inquiéterais pas trop. Il ne fonctionne pas et ne prend aucune ressource et il est juste là pour que le noyau s'en souvienne.

— David Pashley
source

1

eh bien, je dois m'inquiéter. c'est une machine de production exécutant des services de sauvegarde (bacula) et voip (astérisque). tant que le processus bacula-sd défunt est là, bacula ne semble pas accéder au lecteur de bande ...

— andreas-h

Aucun fichier ne devrait être ouvert. Exécutez lsof -p 5825 et vérifiez.

— David Pashley

Eh bien, il semble y avoir beaucoup de choses ouvertes ... voir ci-dessus. Des idées ce que je peux faire? Je n'ai jamais utilisé lsof ...

— andreas-h

1

Oui, votre zombie a ouvert / dev / nst0. Un redémarrage du système est probablement le meilleur pari à ce stade.

— Kyle Smith

5

Oui, le redémarrage semble être la réponse dominante. J'ai toujours l'impression d'avoir échoué lorsque je dois redémarrer un serveur. :(

— David Pashley

3

Vérifiez s'il y a eu une panique du noyau,

# dmesg |tail

Vérifiez si le processus est en veille "D" Unkillable, où il est en mode noyau pour certains appels système qui ne sont pas encore retournés (oups du noyau, ou pour toute autre raison) http://www.nabble.com/What-causes-an -processus inutilisable - td20645581.html

— En pause jusqu'à nouvel ordre.
source

formatage ennuyeux

— asdmin

en fait, il n'y a pas eu de panique du noyau. processus est dans l'état 'Z' - un zombie ...

— andreas-h

3

Si un zombie a init comme parent, alors init a cessé de fonctionner correctement. L'un des rôles de init est de nettoyer les zombies. S'il ne le fait pas, personne d'autre ne le fera. La seule solution est donc de redémarrer. Si l'initialisation est interrompue, un redémarrage peut échouer, donc j'arrêterais des services importants, synchroniserais le système de fichiers puis appuierais sur le bouton d'alimentation à la place.

— MarkR
source

Je suis d'accord sur le fait que l'init ne fonctionne pas correctement. Voir aussi: upstartet systemd.

— Mikko Rantalainen

2

Gardons la panique, d'accord? Un processus «disparu» ou «zombie» n'est pas un processus . Il s'agit simplement d'une entrée dans la table de processus, avec un code de sortie enregistré. Ainsi, un zombie ne détient aucune ressource, ne prend aucun cycle CPU et n'utilise aucune mémoire, car il ne s'agit pas d'un processus . N'obtenez pas tout bizarre et démangeant en essayant de "tuer" les processus zombies. Tout comme leurs homonymes, ils ne peuvent pas être tués, car ils sont déjà morts. Mais contrairement au type mangeur de cerveau, ils ne nuisent absolument à personne et ne mordront pas les autres processus.

Ne laissez pas les processus zombies dévorer votre cerveau. Ignore les.

— Teddy
source

11

Oui, c'est la théorie. Malheureusement, ce n'est pas toujours vrai. Un processus défunt s'accrochera parfois aux ressources système, comme andreash l'a clairement documenté.

— Roy

5

Dans son cas, selon la sortie lsof, le processus zombie mange le cerveau de / dev / nst0. Il a besoin de ces cerveaux pour continuer les opérations de sauvegarde.

— Kyle Smith

2

Un administrateur système qui passe sa carrière à ignorer les processus Zombie se réveillera finalement au milieu de la nuit avec leur vie aspirée. Un zombie est, selon mon expérience, révélateur de quelque chose de mal. Je les écris même lorsqu'un enfant zombie a une interaction étrange avec son parent, et le parent fait tourner mon processeur. Je ne sais pas de qui il s'agit, mais le fait est que les zombies sont laids et les ignorer viendra un jour vous hanter. ... Un jour ... quand tu dors paisiblement ... au milieu de la nuit ... après une froide journée d'automne ...

— Mike S

@MikeS J'ai bien ri de votre commentaire!

— Paul Calabro

@MikeS a raison. J'ai ssh-agent défunt et ssh ni git ne peuvent pas fonctionner correctement. seul le redémarrage peut aider. (même correctif que Windows a ... haha)

— John Tribe

0

On dirait que vous avez un processus orphelin. Pour autant que je sache, la seule façon de les tuer serait de redémarrer la box. J'ai eu ce problème sur mes serveurs ESX (qui sont sous Linux sous le capot) de temps en temps et un redémarrage de l'hôte est le correctif (du support VMware).

Je suis un gars Windows alors prenez ça pour ce que ça vaut.

— mrdenny
source

malheureusement, le redémarrage n'est pas une véritable option. c'est une machine de production qui exécute également des services voip, donc je ne peux pas la redémarrer pendant les heures de bureau ...

— andreas-h

1

donc, vous pouvez le redémarrer après les heures de bureau, non?

— warren