Сигналы, зомби и PID 1: почему контейнер не останавливается по SIGTERM

Что здесь на самом деле спрашивают

Лестница почти всегда одна и та же, и держится она на одном механизме, хотя вопросы выглядят несвязанными:

1. «Что такое зомби-процесс?» — разминка, на которой отсеиваются те, кто думает, что это зависший процесс.
2. «Чем он опасен, если самого процесса уже нет?» — здесь начинается содержание.
3. «Кто становится родителем осиротевшего процесса?» — проверяют, знаете ли вы про усыновление и про subreaper.
4. «Почему контейнер останавливается не сразу?» — вопрос, на который напрашивается ответ «медленно закрывает соединения»: правдоподобно и мимо механизма.
5. «Что означает код выхода 137?» — знаете ли вы арифметику и понимаете ли, чего этот код НЕ говорит.
6. «Зачем в контейнер кладут tini?» — вопрос, который проверяет, связали ли вы первые пять в одно.

Урок идёт по этой лестнице и идёт в одну сторону: сначала правило, потом его следствия. Все числа получены на одной машине прогоном bench/signals/lifecycle.py и bench/signals/practice.py; номера процессов и миллисекунды у вас будут другие, а состояния, коды выхода и исход SIGTERM для PID 1 совпадут.

База: процесс, его номер и сообщение, которое ему шлют

Прежде чем говорить о зомби и о номере 1, стоит назвать обычными словами четыре вещи, на которых держится весь урок.

Процесс — это запущенная программа. Не файл на диске, а его запуск: одна и та же программа, запущенная дважды, — это два процесса, и живут они независимо друг от друга.

У процесса есть номер. Ядро выдаёт его при запуске, и по этому номеру процесс потом находят: чтобы посмотреть на него, остановить или дождаться его конца.

Сигнал — это короткое сообщение процессу. Посылает его ядро или другой процесс, и содержания в нём ровно столько, сколько в самом номере сигнала: «завершись по-хорошему», «прекрати немедленно», «приостановись». Ни текста, ни ответа: сигнал либо что-то с процессом сделал, либо не сделал ничего.

У процессов есть родитель и потомок — тот, кто запустил, и тот, кого запустили. Связь эта не формальная: именно родителю потом достаётся ответ на вопрос, чем кончился потомок.

Из последних двух пунктов прямо следует первая ступень лестницы. Потомок завершился; родитель ещё не спросил, чем всё кончилось; ядру нужно где-то держать ответ на этот будущий вопрос — и оно его держит. Состояние «процесса уже нет, а запись о том, чем он кончился, ещё есть» и называют зомби.

И ещё одно, без чего вторая половина урока читается как магия: у контейнера своё пространство номеров. Процессы внутри нумеруются с единицы, как в только что загрузившейся системе, а снаружи у того же самого процесса номер совсем другой. Один процесс — два номера: внутри 1, снаружи обычный. Тот, кто останавливает контейнер, живёт снаружи и шлёт сигнал по внешнему номеру — а правила к процессу применяются те, которые действуют для номера 1.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования. Дальше — про то, почему один и тот же сигнал по-разному действует на обычный процесс и на процесс с номером 1, кому достаётся потомок, если родитель умер раньше, и откуда в отчёте берётся код 137.

Механизм 1: смерть процесса — это два события, а не одно

Теперь то же самое словами документации — и начнём с того, что не зависит ни от дистрибутива, ни от версии ядра.

Процесс заканчивается дважды. Сначала он перестаёт выполняться — вызывает exit, получает фатальный сигнал, падает. Потом кто-то забирает его статус — вызывает wait. Между этими двумя событиями процесса уже нет, а запись о нём есть.

Эта запись и называется зомби. wait(2) говорит о ней прямо:

Отсюда сразу ответ на второй вопрос лестницы. Зомби опасен не тем, что «висит в памяти»: адресного пространства процесса уже нет, а то, что осталось, — минимальный набор сведений, перечисленный в цитате выше. Опасен он тем, что эта запись занимает слот в таблице процессов, а таблица конечна:

Так выглядит утечка, у которой в графике памяти ничего не видно. Приложение работает, память ровная, а fork в какой-то момент перестаёт удаваться — и падает не тот, кто виноват.

Вот это в прогоне. Потомок вызвал _exit(7) и был оставлен без wait:

1. ZOMBIE: the child is gone, the record is not
-----------------------------------------------
  child finished, status not collected       Z (zombie)
  why the kernel keeps the record            so the parent can read the exit code
  state after wait                           no such process
  exit code the record was held for          7

Четыре строки читаются как история целиком: состояние Z до wait, ничего после wait, и семёрка — то самое, ради чего запись держалась. Убирает зомби не время и не сборщик, а вопрос «чем всё кончилось», заданный родителем.

Механизм 2: у сироты новый родитель, и это не абстракция

Обратный случай: родитель умер раньше потомка. Потомок при этом не умирает и не остаётся без родителя — его усыновляют.

Прогон показывает сам момент замены. Внук печатает своего родителя дважды — сразу после запуска и после того, как его отец завершился:

2. ORPHAN: the parent died first
--------------------------------
  grandchild: parent right after start    5359
  grandchild: parent after father exits   1

Число 5359 у вас будет другим, единица — та же. И вот что из этого следует для работы: забирать статус сироты будет новый родитель, а не потерянный. Если новый родитель это умеет — зомби не копятся. Если не умеет — копятся все сироты сразу, и это ровно то, что происходит в контейнере, где первым процессом оказалось обычное приложение.

Слово subreaper здесь не для красоты: так называют процесс, который сказал ядру «сироты моего поддерева достаются мне, а не первому процессу». Говорится это вызовом PR_SET_CHILD_SUBREAPER; так устроены менеджеры сессий и системы супервизии. В контейнере такого процесса обычно нет, и сироты идут прямо к PID 1.

Механизм 3: правило PID 1, из которого растёт всё остальное

Теперь главное. У процесса, который в своём пространстве имён получил номер 1, сигналы работают иначе — и это записано в pid_namespaces(7):

Снаружи — то же самое, и это как раз случай оркестратора: он живёт в родительском пространстве имён и шлёт сигнал вашему первому процессу.

Сформулируем это словами, которыми стоит отвечать: для PID 1 умолчательные действия сигналов не выполняются. Диспозиция сигнала — это то, что процесс с ним делает: умолчательное действие из таблицы signal(7) (у SIGTERM там стоит Term — завершиться), игнорирование или обработчик. У обычного процесса без обработчика работает умолчательное действие. У процесса с номером 1 умолчательного действия нет вовсе: обработчик поставлен — сигнал работает, не поставлен — сигнал не делает ничего.

Один и тот же SIGTERM, два процесса, отличающиеся одной строкой:

3. PID 1: one SIGTERM, two outcomes
-----------------------------------
  PID inside the namespace (no handler)      1
  SIGTERM from outside, no handler (PID 5362) ALIVE: the signal did nothing
  PID inside the namespace (with handler)    1
  SIGTERM from outside, with handler (PID 5364) exited

Обратите внимание, что сигнал шлётся снаружи и по внешнему номеру (5362), а внутри пространства имён у этого процесса номер 1. Так же поступает и оркестратор: он не заходит внутрь контейнера, он посылает сигнал процессу, который снаружи выглядит обычным.

Есть исключение, и оно ровно одно:

Поэтому «контейнер невозможно остановить» — неверная формулировка. Остановить можно всегда; вопрос в том, ждёт ли оркестратор перед этим весь льготный срок впустую.

Механизм 4: сколько стоит отсутствие обработчика и откуда в отчёте 143 и 137

Остановка контейнера — это три шага: SIGTERM, льготный срок, SIGKILL. Длину срока задаёт тот, кто останавливает, и она называется в его настройках; для урока важно не конкретное число, а то, что срок конечен и после него приходит сигнал, который не ловится. Разница между «остановился за миллисекунды» и «остановился за весь срок» — это ровно наличие обработчика.

Скрипт воспроизводит эту схему со сроком в две секунды:

stop time, SIGTERM handled           11 ms
stop time, no handler                2009 ms

Второе число — не «медленное завершение». Это весь срок ожидания плюс время, за которое доходит SIGKILL: процесс всё это время жив и здоров, SIGTERM для него не произошёл, а потом приходит SIGKILL, который не ловится.

Дальше арифметика кодов выхода. Ядро отдаёт две разные вещи: код, с которым процесс вышел сам, и номер сигнала, которым его убили. Складывает их тот, кто печатает результат:

Отсюда и таблица, которую спрашивают:

4. EXIT CODES: 128 + signal number
----------------------------------
  exited on its own                          3
  SIGTERM, default disposition               -15 (the shell reports 143)
  SIGKILL                                    -9 (the shell reports 137)

143 — это 128 + 15, SIGTERM. 137 — это 128 + 9, SIGKILL. Минус пятнадцать — то, как отдаёт номер сигнала subprocess: отрицательное число, чтобы его нельзя было спутать с кодом выхода.

И самое полезное здесь — чего код 137 не говорит. Он говорит: процесс убит SIGKILL. Он не говорит, кто послал сигнал. OOM-killer, оркестратор после льготного срока, человек с kill -9 — в этой графе неразличимы, и в логе приложения не будет ничего, потому что SIGKILL не даёт выполнить ни одной строки. Различать их придётся по другим уликам: сообщению ядра, событию оркестратора, времени.

Глубже: зачем в контейнер кладут init

Теперь все части складываются. Ваше приложение стало PID 1, а значит:

• умолчательные действия сигналов для него не выполняются, и SIGTERM без обработчика не сделает ничего;
• все сироты в контейнере усыновляются им, и забирать их статусы тоже придётся ему.

Обычное приложение не делает ни того, ни другого: оно не рассчитывало быть первым процессом. Отсюда две классические поломки: контейнер, который останавливается только по таймауту, и контейнер, в котором тихо копятся зомби от каждого запущенного подпроцесса.

Отсюда роль, для которой написаны маленькие init-процессы (tini, dumb-init, флаг docker run --init): занять PID 1 и закрыть обе обязанности — пересылать сигналы дочернему процессу и забирать статусы сирот. Правило про умолчательные действия становится заботой такого процесса, а не вашей; что именно умеет конкретный из них, написано в его документации.

Замена ему — не библиотека, а две строки в приложении: поставить обработчик SIGTERM и вызывать wait для потомков. Если приложение не порождает процессов, достаточно первого.

Как отвечать на собеседовании

Короткий ответ: у процесса с номером 1 в своём пространстве имён умолчательные действия сигналов не выполняются, поэтому SIGTERM без обработчика для него не делает ничего — оркестратор ждёт весь льготный срок и добивает SIGKILL, а в отчёте остаётся код 137, то есть 128 + 9. Зомби при этом — не процесс, а запись о его смерти: она держится ради кода выхода и занимает слот в таблице процессов, а убирает её wait, а не время.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Хороший ответ отличается двумя вещами. Первая — вы называете правило правилом ядра, а не особенностью Docker, и знаете исключение: SIGKILL и SIGSTOP из родительского пространства имён доставляются принудительно, поэтому остановить можно всегда, вопрос только в задержке. Вторая — вы говорите, чего код 137 не сообщает: кто послал сигнал. Ответ «137 значит OOM» превращает улику в диагноз — а это разные вещи.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

pid = os.fork()
if pid == 0:
  os._exit(7)
time.sleep(0.2)
print(state_of(pid))
print(os.waitstatus_to_exitcode(os.waitpid(pid, 0)[1]))
print(orphan_ppid())
print(pid1_state_after_sigterm(SLEEPER))
killed = subprocess.Popen([sys.executable, "-c", "import time; time.sleep(5)"])
time.sleep(0.2)
killed.send_signal(signal.SIGKILL)
print(128 - killed.wait())

Z
7
1
S
137

Z
7
0
S
143

S
7
1
Z
137

Z
0
1
S
143

Проверка знаний