Proces, który się zamyka, ignoruje SIGKILL, można uruchomić (nie jest to zombie ani nieprzerwany sen). W jakim jest stanie?

Mam proces, który kilka razy teraz przestał odpowiadać i wydaje się całkowicie blokować. Nie reaguje na żadną próbę śledzenia lub podglądania za pomocą gdb (gdb po prostu zawiesza się na wywołaniu systemowym wait4 ()). Proces można uruchomić i nie czeka on na wywołanie systemowe (/ proc / X / syscall:) runninglub nieprzerwany sen (/ proc / X / status:) State: R (running).

W jakim stanie jest dokładnie ten proces? Czy to jest jakiś błąd jądra?

Proces jest redis i zdarzyło się to już kilka razy. Wydaje się, że jedyną rzeczą, która może zabić ten proces, jest restart. System operacyjny to Cent 7.

Edycja: Wersja jądra to 3.10.0-123.13.2.el7.x86_64. Próbuję zaktualizować do wersji 3.10.0-229.11.1.el7, aby sprawdzić, czy to coś zmienia.

process linux-kernel redis

— Alienth
źródło

Jakiej wersji GDB używa? Według stackoverflow.com/questions/8978777/ ... nowsza wersja może działać lepiej.

— Greg Bray,

Obecnie wygląda na to, że śledztwo jest bardziej po stronie jądra ze względu na specjalny sposób zawieszania się, ale jeśli nie masz nic przeciwko, możesz dodać kilka szczegółowych informacji Redis? Co robi proces, gdy się blokuje i takie tam. Dostałem kilka informacji od Nicka Cravera za pośrednictwem Twittera, najwyraźniej Redis ładuje duży zestaw danych, gdy to się dzieje, czy zestaw danych jest ładowany po prostu ponownie uruchamiając proces lub w inny sposób (na przykład za pośrednictwem DEBUG RELOAD lub potokowania dużych ilości danych )? Dzięki.

@antirez Zestaw danych jest ładowany przez kopię rdb z innej instancji redis. Blokady występują po uruchomieniu redis i odczytaniu w gigantycznym dysku CD. W szczególności nie zawsze się to zawiesza, tylko czasami.

— alienth

Miałem tylko tego rodzaju problemy, gdy miałem błędy We / Wy. Czy możesz nam powiedzieć o dmesgwynikach?

— Ho 1

Co zawiera /proc/<pid>/stack(i /proc/<pid>/task/*/stack)? Czy ten proces ma kilka wątków?

— Stéphane Chazelas,

wait4 to syscall wskazujący, że proces czeka na jedno z jego zakończeń potomnych. Może to wskazywać na pewien problem z obsługą sygnału.

Trochę brutalne, ale można próbować zabić hierarchii app: kill -15 -$YourRedisPID. Znak - przed PID oznacza „PID i jego dzieci”. Ponieważ wydaje się, że czeka na zakończenie dziecka, może je odblokować.

Jeśli to nie działa, sprawdźmy głębiej: znajdź swój status procesu przetwarzania za pomocą grep ^Sig /proc/$YourRedisPID/status

Zobaczysz takie rzeczy jak:

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

Jak zdefiniowano w „fs / proc / array.c” źródła jądra, „SigQ” jest liczbą oczekujących sygnałów / limitem oczekujących sygnałów.

Jeśli liczba sygnałów jest zbyt wysoka, może to oznaczać, że Twój „SIGKILL” nie jest w ogóle obsługiwany. Nadal sprawdzam plik „kernel / signal.c”, aby zrozumieć zarządzanie sygnałami tych specjalnych sygnałów.

Aby uzyskać bezpośrednie zrozumienie danych wyjściowych, wypróbuj ten jeden wiersz: awk 'BEGIN{print "ibase=16;obase=2;"} /^Sig...:/{ print toupper($2)}' /proc/$YourRedisPID/status | BC_LINE_LENGTH=0 bc

To daje mi:

0
0
10000000
110000000000000000100000000100011

Zacznijmy od wysłania nam tego wyjścia. Zaktualizuję post zgodnie z wymaganiami.

— Adrien M.
źródło

Proces nie jest w wait4 (), gdb jest zawieszany na wait4 () podczas próby uzyskania dostępu do procesu. Sam proces nie znajduje się w żadnym wywołaniu systemowym. Ponadto proces zawieszenia nie ma dzieci. Niestety musiałem zrestartować urządzenie. Zbierzę dane, o które prosiłeś, gdy problem wystąpi ponownie.

— alienth

Wyjście tutaj: gist.githubusercontent.com/alienth/23685ad2ea46a7eade56/raw/... Po raz kolejny proc ignoruje SIGKILL. Nie jest to wywołanie systemowe. Proc ignoruje również SIGTERM.

— alienth