Процес, який замикається, ігнорує SIGKILL, піддається виконанню (не в зомбі або в режимі безперервного сну). У якому стані він знаходиться?

У мене є процес, який вже кілька разів переставав реагувати і, здається, повністю замикається. Він не відповідає на будь-яку спробу затягування чи зазирнення за допомогою gdb (gdb просто висить на syscall wait4 ()). Процес запущений і не чекає на системному дзвінку (/ proc / X / syscall:) runningабо в режимі безперебійного сну (/ proc / X / status :) State: R (running).

В якому саме стані знаходиться цей процес? Це можливо помилка ядра якогось типу?

Процес переробляється, і це вже кілька разів трапляється. Здається, єдине, що може вбити процес - це перезавантаження. ОС є Cent 7.

Редагувати: версія ядра - 3.10.0-123.13.2.el7.x86_64. Спробуйте оновити до 3.10.0-229.11.1.el7, щоб побачити, чи це має значення.

process linux-kernel redis

— другий
джерело

Яку версію GDB він використовує? Згідно з stackoverflow.com/questions/8978777/…, новіша версія може працювати краще.

— Грег Брей

В даний час схоже, що розслідування є більш ядерним у зв’язку із особливим способом, який він зависає, але якщо ви не заперечуєте, чи можете ви додати кілька конкретних відомостей про Redis? Що процес робить, поки він блокує і подібні речі. Я отримав декілька інформації від Ніка Крейвера через Twitter, мабуть, Redis завантажує великий набір даних, коли це відбувається, чи завантажений набір даних просто перезапускає процес чи іншим способом (наприклад, за допомогою DEBUG RELOAD або конвеєром великих обсягів даних )? Спасибі.

@antirez Набір даних завантажується копією rdb з іншого екземпляра redis. Блокування відбувається після запуску Redis та читання в гігантському rdb. Примітно, що це не завжди блокується під час цього, а іноді.

— 10:00

У мене виникли такі проблеми, коли були помилки в IO. Не могли б ви сказати нам про dmesgвихід?

— Ho1

Що містить /proc/<pid>/stack(і /proc/<pid>/task/*/stack)? Чи отримав цей процес кілька тем?

— Стефан Шазелас

wait4 - це системний виклик, який вказує на те, що процес очікує закінчення одного з його дітей. Це може вказувати на певну проблему з обробкою сигналу.

Трохи жорстоко, але ви можете спробувати вбити ієрархію з програми: kill -15 -$YourRedisPID. - до PID означає «PID і його дітей». Оскільки, здається, чекає припинення дитини, вона може її розблокувати.

Якщо це не працює, давайте перевіримо глибше: знайдіть стан свого сигналу за допомогою grep ^Sig /proc/$YourRedisPID/status

Ви побачите такі речі, як:

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

Як визначено у "fs / proc / array.c" джерела ядра, "SigQ" - це кількість сигналів, що очікують / межа сигналів, що очікують на розгляд.

Якщо кількість сигналу занадто велика, це може означати, що ваш "SIGKILL" взагалі не обробляється. Я все ще перевіряю файл "kernel / signal.c", щоб зрозуміти управління сигналами цих спеціальних сигналів.

Для прямого розуміння результатів спробуйте скористатися цим одноклапником: awk 'BEGIN{print "ibase=16;obase=2;"} /^Sig...:/{ print toupper($2)}' /proc/$YourRedisPID/status | BC_LINE_LENGTH=0 bc

Це виводить мене:

0
0
10000000
110000000000000000100000000100011

Почнемо, надіславши нам цей вихід. Я оновлю публікацію, як потрібно.

— Адрієн М.
джерело

Процес не в режимі wait4 (), gdb підвішується на wait4 () при спробі отримати доступ до процесу. Сам процес не знаходиться в жодному системному виклику. Також підвісний процес не має дітей. На жаль, довелося перезавантажити коробку. Я зберу дані, які ви запитували, як тільки проблема повторно з'явиться.

— осені

Вихід сюди: gist.githubusercontent.com/alienth/23685ad2ea46a7eade56/raw/… Ще раз, Pro ігнорує SIGKILL. Це не в системному дзвінку. Proc також ігнорує SIGTERM.

— о 10-го