Le processus qui se bloque, ignore SIGKILL, est exécutable (pas un zombie ou en veille sans interruption). Dans quel état est-il?

J'ai un processus qui à plusieurs reprises a cessé de répondre et semble se bloquer complètement. Il ne répond à aucune tentative de strace ou de lecture avec gdb (gdb se bloque simplement sur un syscall wait4 ()). Le processus est exécutable et n'attend pas un appel système (/ proc / X / syscall:) runningou en veille ininterrompue (/ proc / X / status :) State: R (running).

Dans quel état se trouve ce processus exactement? Est-ce peut-être un bug du noyau d'un certain type?

Le processus est redis, et cela s'est produit plusieurs fois maintenant. La seule chose qui peut tuer le processus est un redémarrage, semble-t-il. OS est Cent 7.

Edit: la version du noyau est 3.10.0-123.13.2.el7.x86_64. Essayer une mise à jour vers 3.10.0-229.11.1.el7 pour voir si cela fait une différence.

process linux-kernel redis

— alienth
source

Quelle version de GDB utilise-t-elle? Selon stackoverflow.com/questions/8978777/… une version plus récente pourrait mieux fonctionner.

— Greg Bray

Actuellement, il semble que l'enquête soit plus côté noyau en raison de la façon particulière dont elle se bloque, mais si cela ne vous dérange pas, pourriez-vous ajouter quelques informations spécifiques à Redis? Ce que fait le processus pendant qu'il bloque et des choses comme ça. J'ai reçu quelques informations de Nick Craver via Twitter, apparemment Redis charge un grand ensemble de données lorsque cela se produit, est-ce que l'ensemble de données est chargé juste en redémarrant le processus ou d'une autre manière (par exemple via DEBUG RELOAD, ou en canalisant de grandes quantités de données )? Merci.

@antirez L'ensemble de données est en cours de chargement par une copie rdb d'une autre instance redis. Les blocages se produisent après le démarrage de redis et la lecture dans le rdb géant. Notamment, il ne se bloque pas toujours pendant cela, juste parfois.

— alienth

Je n'ai eu ce genre de problèmes que lors d'erreurs d'E / S. Pourriez-vous s'il vous plaît nous parler de la dmesgsortie?

— Ho1

Que contient /proc/<pid>/stack(et /proc/<pid>/task/*/stack) contient? Ce processus a-t-il plusieurs fils?

— Stéphane Chazelas

wait4 est un appel système indiquant que le processus attend la terminaison d'un de ses enfants. Cela peut signaler un problème avec la gestion du signal.

Un peu brutal, mais vous pouvez essayer de tuer la hiérarchie de l'application: kill -15 -$YourRedisPID. Le - avant le PID signifie "le PID et ses enfants". Comme il semble attendre la fin d'un enfant, il peut le déverrouiller.

Si cela ne fonctionne pas, vérifions plus en profondeur: trouvez l'état de votre processus de signal avec grep ^Sig /proc/$YourRedisPID/status

Vous verrez des trucs comme:

SigQ:   8/62777
SigPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000080
SigCgt: 0000000180004023

Comme défini dans "fs / proc / array.c" de la source du noyau, le "SigQ" est le nombre de signaux en attente / la limite des signaux en attente.

Si le nombre de signaux est trop élevé, cela peut indiquer que votre "SIGKILL" n'est pas géré du tout. Je vérifie toujours le fichier "kernel / signal.c" pour comprendre la gestion du signal de ces signaux spéciaux.

Pour une compréhension directe de la sortie, essayez ce one-liner: awk 'BEGIN{print "ibase=16;obase=2;"} /^Sig...:/{ print toupper($2)}' /proc/$YourRedisPID/status | BC_LINE_LENGTH=0 bc

Cela me produit:

0
0
10000000
110000000000000000100000000100011

Commençons par nous envoyer cette sortie. Je mettrai à jour le message au besoin.

— Adrien M.
source

Le processus n'est pas dans wait4 (), gdb est suspendu à un wait4 () lors de la tentative d'accès au processus. Le processus lui-même n'est dans aucun appel système. De plus, le processus suspendu n'a pas d'enfants. Malheureusement, j'ai dû redémarrer la box. Je recueillerai les données que vous avez demandées une fois que le problème se reproduira.

— alienth

Sortie ici: gist.githubusercontent.com/alienth/23685ad2ea46a7eade56/raw/… Encore une fois, proc ignore SIGKILL. Ce n'est pas dans un appel système. Proc ignore également SIGTERM.

— alienth