Il processo che si blocca, ignora SIGKILL, è eseguibile (non uno zombi o in un sonno ininterrotto). In che stato si trova?

Ho un processo che diverse volte ha smesso di rispondere e sembra bloccarsi completamente. Non risponde a nessun tentativo di strace o sbirciare con gdb (gdb si blocca solo su un syscall wait4 ()). Il processo è eseguibile e non è in attesa su un syscall (/ proc / X / syscall:) runningo in modalità di sospensione ininterrotta (/ proc / X / status:) State: R (running).

In quale stato si trova esattamente questo processo? È forse un bug del kernel di qualche tipo?

Il processo è redis e questo è successo alcune volte. L'unica cosa che può uccidere il processo è un riavvio, a quanto pare. Il sistema operativo è Cent 7.

Modifica: la versione del kernel è 3.10.0-123.13.2.el7.x86_64. Prova un aggiornamento a 3.10.0-229.11.1.el7 per vedere se questo fa la differenza.

process linux-kernel redis

— alienth
fonte

Quale versione di GDB sta usando? Secondo stackoverflow.com/questions/8978777/… una versione più recente potrebbe funzionare meglio.

— Greg Bray il

Attualmente sembra che l'indagine sia più lato kernel a causa del modo speciale in cui si blocca, ma se non ti dispiace, potresti aggiungere alcune informazioni specifiche di Redis? Cosa sta facendo il processo mentre si blocca e cose del genere. Ho ricevuto alcune informazioni da Nick Craver via Twitter, a quanto pare Redis sta caricando un set di dati di grandi dimensioni quando ciò accade, è il set di dati caricato appena riavvia il processo o in qualche altro modo (ad esempio tramite DEBUG RELOAD o pipeline di grandi quantità di dati )? Grazie.

@antirez Il set di dati viene caricato da una copia rdb da un'altra istanza redis. I blocchi si verificano dopo che redis si avvia e legge nel gigantesco rdb. In particolare non sempre si blocca durante questo, solo a volte.

— alienth,

Ho avuto questo tipo di problemi solo con errori di I / O. Potresti parlarci dmesgdell'output?

— Ho1,

Cosa contiene /proc/<pid>/stack(e /proc/<pid>/task/*/stack)? Questo processo ha più thread?

— Stéphane Chazelas,

wait4 è un syscall che indica che il processo è in attesa di una sua conclusione figlio. Ciò può indicare alcuni problemi con la gestione del segnale.

Un po 'brutale, ma si può cercare di uccidere la gerarchia delle app: kill -15 -$YourRedisPID. Il - prima del PID significa "il PID e i suoi figli". Dato che sembra essere in attesa di una risoluzione figlio, potrebbe sbloccarlo.

Se non funziona, controlliamo più a fondo: trova lo stato del processo del segnale con grep ^Sig /proc/$YourRedisPID/status

Vedrai alcune cose come:

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

Come definito in "fs / proc / array.c" della sorgente del kernel, "SigQ" è il numero di segnali in sospeso / il limite di segnali in sospeso.

Se il numero del segnale è troppo alto, potrebbe indicare che "SIGKILL" non è gestito affatto. Sto ancora controllando il file "kernel / signal.c" per capire la gestione del segnale di questi segnali speciali.

Per una comprensione diretta dell'output, prova questo one-liner: awk 'BEGIN{print "ibase=16;obase=2;"} /^Sig...:/{ print toupper($2)}' /proc/$YourRedisPID/status | BC_LINE_LENGTH=0 bc

Questo mi dà:

0
0
10000000
110000000000000000100000000100011

Iniziamo inviandoci questo output. Aggiornerò il post come richiesto.

— Adrien M.
fonte

Il processo non è in wait4 (), gdb è bloccato su wait4 () quando si tenta di accedere al processo. Il processo stesso non è in alcun modo. Inoltre, il processo di blocco non ha figli. Sfortunatamente ho dovuto riavviare il box. Raccoglierò i dati richiesti una volta che il problema si ripresenta.

— alienth,

Uscita qui: gist.githubusercontent.com/alienth/23685ad2ea46a7eade56/raw/… Ancora una volta, proc sta ignorando SIGKILL. Non è in un syscall. Proc ignora anche SIGTERM.

— alienth,