Чек-лист безопасной работы с дочерними процессами в Windows-приложении

Скачать Excel-чек-лист (с японским и английским листами)

Инструменты конвертации, updater’ы, worker’ы для анализа, внешние CLI, PowerShell, ffmpeg, внутренние утилиты. Windows-приложения начинают зависеть от дочерних процессов гораздо легче, чем может показаться.

Но сбои возникают не в вопросе «удалось ли запустить процесс».

• Родитель упал, а дочерний процесс продолжает жить
• Выжившим остаётся только процесс-внук
• stdout / stderr забиваются, и WaitForExit не возвращает управление
• watchdog падает вместе с объектом наблюдения
• Казалось, что Kill(entireProcessTree: true) завершил работу, но на деле раньше завершилось только наблюдение

Секрет безопасной работы с дочерними процессами в Windows не в выборе API для запуска, а в том, чтобы определить владельца дерева процессов и спроектировать процедуру завершения и ввод-вывод.

В этой статье мы собираем воедино Job Object, распространение сигнала завершения, стандартные потоки ввода-вывода и watchdog как единую архитектуру.

1. Сначала — главный вывод

Сначала перечислим только то, что важнее всего на практике.

• Если нужно связать время жизни дерева дочерних процессов с жизнью родителя, отправная точка — Job Object
• Запрос завершения консоли и восстановление дерева процессов — разные вещи
  • первое — это группа процессов и GenerateConsoleCtrlEvent
  • второе — это Job Object
• Если процессы должны попадать в Job уже в момент запуска, естественное решение — использовать STARTUPINFOEX и PROC_THREAD_ATTRIBUTE_JOB_LIST
• Стандартный вывод и вывод ошибок нужно вычитывать параллельно — это базовое правило
• Если используется stdin, нужно спроектировать процесс вплоть до закрытия после записи, чтобы передать EOF
• watchdog безопаснее размещать вне Job, за которым он наблюдает
• Kill(entireProcessTree: true) в .NET удобен как API для явной остановки, но не заменяет архитектуру, включающую автоматическое восстановление при падении родителя и штатное завершение

2. В чём именно опасность

Реализация запуска дочернего процесса обычно укладывается примерно в 10 строк. Но сбои случаются за пределами этих 10 строк.

• После падения родителя дочерние и внучатые процессы продолжают работать
• Helper запускает ещё один helper, а ожидание ограничивается только непосредственным дочерним процессом — и на этом успокаиваются
• Одна из сторон stdout / stderr забивается, и родитель с дочерним процессом начинают ждать друг друга
• Ожидание выполняется в UI-потоке, и зависают и окно, и COM
• watchdog разделяет судьбу объекта наблюдения и падает вместе с ним при сбое

Здесь важно понимать: «управление дочерними процессами» — это не вопрос одного API.

Как минимум эти четыре аспекта стоит рассматривать раздельно — так картина становится понятнее.

1. Кто владеет деревом процессов
2. Как запрашивается кооперативное завершение
3. Как организован поток стандартного ввода-вывода
4. Как отслеживаются аварийное завершение и зависания

3. Не смешивайте роли разных механизмов

Дескриптор процесса, группа процессов и Job Object похожи внешне, но играют разные роли.

Группа процессов — это механизм, определяющий, куда доставляется сигнал консоли, а не механизм, который сносит всё дерево при гибели родителя. Job Object, напротив, — это собственный механизм Windows для управления группой процессов как единым целым.

4. Возьмите Job Object за отправную точку

Самое сильное свойство Job Object — то, что он объединяет дерево процессов по признаку «к какому Job принадлежит», а не «чей это дочерний процесс». Дочерние процессы, созданные через CreateProcess процессом внутри Job, по умолчанию присоединяются к этому же Job.

Более того, если добавить JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE, все процессы, связанные с Job, завершаются в момент закрытия последнего дескриптора job.

4.1. Четыре момента, которые стоит закрепить в первую очередь

1. Если дерево должно очищаться при завершении родителя — используйте KILL_ON_JOB_CLOSE

Это основа для работы с helper’ами и worker’ами в Windows-приложении. Архитектура с явным вызовом TerminateJobObject тоже допустима, но если вы хотите привязать очистку к времени жизни родителя, включая его аварийное завершение, KILL_ON_JOB_CLOSE — более понятный вариант.

2. Не добавляйте BREAKAWAY бездумно

JOB_OBJECT_LIMIT_BREAKAWAY_OK и JOB_OBJECT_LIMIT_SILENT_BREAKAWAY_OK выглядят удобными, но именно они часто становятся причиной того, что часть дерева ускользает из-под контроля, хотя предполагалась его очистка целиком. Если нет намеренной причины, отказ от breakaway снижает вероятность сбоя.

3. Если процессы должны попадать в Job с момента запуска — используйте PROC_THREAD_ATTRIBUTE_JOB_LIST

Присоединить процесс к Job можно и позже, вызовом AssignProcessToJobObject. Но там, где нужно гарантировать принадлежность к Job уже в момент запуска, правильнее указать Job при создании процесса через STARTUPINFOEX и PROC_THREAD_ATTRIBUTE_JOB_LIST.

4. Не оставляйте владельца дескриптора job неопределённым

KILL_ON_JOB_CLOSE срабатывает в момент закрытия последнего дескриптора. А значит, если дескриптор job окажется продублирован в другой процесс или неосознанно унаследован, очистка при гибели родителя не сработает так, как ожидалось. Кто является конечным владельцем дескриптора job — этот вопрос стоит решить заранее.

4.2. Job Object пригоден и для наблюдаемости, но уведомления не всесильны

С Job Object можно связать порт завершения ввода-вывода (I/O completion port) для получения уведомлений. Однако уведомления через completion port безопаснее не считать полностью гарантированными во всех случаях.

Поэтому completion port удобен для:

• мониторинга;
• агрегации;
• логирования;
• метрик,

но не стоит строить на нём одном корректность работы системы.

5. Проектируйте распространение сигнала завершения как протокол с тайм-аутом

Завершение дочернего процесса — это не вопрос, решаемый одним вызовом kill. Наименее подвержена сбоям схема из трёх этапов.

1. Запросить кооперативное завершение
2. Подождать короткий тайм-аут
3. В конце принудительно завершить весь Job

При таком порядке сохраняется нормальный путь завершения, но при зависании дерево всё равно можно восстановить.

5.1. GUI-процесс

Для дочернего процесса с графическим интерфейсом в .NET вызов CloseMainWindow отправляет сообщение закрытия. Но это запрос на завершение, а не принудительное завершение. Поэтому логичнее выстроить такой порядок:

• CloseMainWindow
• подождать некоторое время
• если не помогло — завершить весь Job

5.2. Консольный дочерний процесс

Для консольного дочернего процесса сообщение закрытия GUI недоступно. Здесь используются группа процессов и сигналы консоли.

Порядок действий: запуск с CREATE_NEW_PROCESS_GROUP, затем отправка CTRL_BREAK_EVENT через GenerateConsoleCtrlEvent. Здесь важны такие моменты:

• CTRL_C_EVENT плохо подходит для адресации конкретной группе;
• сигнал могут получить только процессы, разделяющие одну консоль;
• использование CREATE_NEW_PROCESS_GROUP меняет и смысл CTRL+C.

5.3. Worker / headless-процесс

Worker и headless-процессы часто не являются ни GUI-, ни консольными. В этом случае безопаснее иметь отдельный протокол завершения для дочернего процесса.

• отправить quit через stdin;
• отправить команду завершения через именованный канал / сокет / RPC;
• передать запрос остановки через объект события.

Разделение, которое снижает вероятность сбоя: на стороне Windows за очистку дерева отвечает Job Object, а на стороне приложения за штатное (graceful) завершение отвечают канал или stdin.

6. Не допускайте забивания стандартных потоков ввода-вывода

6.1. stdout / stderr — вычитывать параллельно

Первое базовое правило звучит так. stdout и stderr нужно вычитывать параллельно. Схема, при которой сначала полностью читается одна сторона, а затем другая, легко приводит к зависанию.

Каналы Windows не обладают бесконечным буфером. Если дочерний процесс активно пишет в stderr, а родитель читает только stdout, обычным делом становится ситуация, когда дочерний процесс останавливается на записи, а родитель — в ожидании завершения.

6.2. Если используется stdin, проектируйте вплоть до EOF

Возможность писать в stdin и способность дочернего процесса завершиться — не одно и то же.

• ввод записан, но канал не закрыт;
• родитель считает, что «уже всё передал»;
• дочерний процесс думает, что «данные ещё будут», и продолжает ждать.

Такое состояние действительно возникает. Если используется stdin, архитектура должна включать закрытие канала после записи, чтобы передать EOF.

6.3. Обязательно закрывайте неиспользуемые концы канала

Если не закрыть неиспользуемые концы канала на стороне родителя или дочернего процесса, EOF не распространяется, и условие завершения нарушается. Это простая, но на практике весьма распространённая причина сбоев.

6.4. Не оставляйте неопределёнными UseShellExecute=false и наследование дескрипторов

Если используется перенаправление стандартного ввода-вывода, в .NET обязательным условием является UseShellExecute=false. В Win32 также безопаснее максимально сузить то, что именно наследуется. Если оставить bInheritHandles=TRUE и унаследовать всё подряд, это становится источником неожиданных утечек дескрипторов.

7. Размещайте watchdog «снаружи»

Самое важное при добавлении watchdog — не помещать его в тот же Job, что и объект наблюдения. Если worker падает и его нужно перезапустить, а роль перезапуска гибнет вместе с ним, в этом нет смысла.

7.1. Наблюдение за завершением стройте на объектах ожидания

Когда процесс завершается, он переходит в сигнальное состояние. Поэтому наблюдение за завершением в принципе не требует цикла опроса, проверяющего HasExited каждые 100 мс.

В Win32 правильными инструментами являются:

• WaitForSingleObject
• WaitForMultipleObjects
• RegisterWaitForSingleObject
• SetThreadpoolWait

Если обрабатывается несколько дочерних процессов, наблюдение на основе объектов ожидания естественнее, чем опрос по таймеру.

7.2. Не выполняйте бесконечное ожидание в UI-потоке

WaitForSingleObject(INFINITE) удобен, но, если использовать его в потоке, владеющем окном, это легко останавливает насос сообщений (message pump). Для UI-потоков, потоков COM-апартамента и потоков с насосом сообщений безопаснее заранее продумать, где именно размещается ожидание.

7.3. Watchdog для зависаний требует heartbeat

Для watchdog, отслеживающего завершение, достаточно дескриптора процесса. А вот watchdog для зависаний — совсем другое дело.

• процесс завис при загрузке CPU 100%;
• возник deadlock;
• цикл обработки событий жив, но не продвигается;
• процесс завис в ожидании ввода.

Такие состояния нельзя определить одним лишь фактом «жив ли процесс». Поэтому, если нужно отслеживать и зависания, требуется проверка живости на уровне приложения, например:

• heartbeat;
• последовательность прогресса;
• метка времени последней успешной операции;
• проверка работоспособности (health probe).

7.4. Роль перезапуска размещайте вне объекта наблюдения

На практике распространены два таких паттерна.

• Родительское приложение временно запускает helper
  • родитель владеет Job; при завершении родителя восстанавливается всё дерево helper’а
• Долговременно работающий worker должен перезапускаться после падения
  • внешний процесс или служба watchdog создаёт отдельный Job для каждого нового поколения worker’а

Во втором случае архитектура стабильнее, если отделить дерево worker’а от полномочий на перезапуск.

7.5. Держите политику перезапуска в виде бюджета

Как только появляется watchdog, следом начинается цикл падений (crash loop).

• немедленный перезапуск;
• немедленное повторное падение;
• в логах накапливается только шум.

Чтобы этого избежать, стоит вести бюджет перезапусков:

• задержка с нарастанием (backoff);
• ограничение числа перезапусков за заданный промежуток времени;
• при подряд идущих сбоях — остановка и уведомление.

8. Рекомендуемая конфигурация для типовых сценариев

Здесь важнее всего разделить механизм штатного завершения и механизм очистки.

9. Чего делать не стоит

• Считать, что один Kill(entireProcessTree: true) решает и штатное завершение, и восстановление при падении родителя
• Оставлять bInheritHandles=TRUE и наследовать всё подряд
• Полностью читать stdout, прежде чем начать читать stderr
• Не закрывать неиспользуемые концы канала
• Вызывать WaitForSingleObject(INFINITE) в UI-потоке
• Помещать watchdog в тот же Job, что и объект наблюдения
• Использовать 259 как обычный код выхода
• Считать уведомления completion port единственным источником истины

10. Итог

При безопасной работе с дочерними процессами в Windows-приложении лучше всего помогает такая формулировка:

Кто владеет деревом процессов? Как передаётся запрос на завершение? Как организовано вычитывание стандартного ввода-вывода до конца? Где размещается watchdog?

Эти четыре вопроса нужно решить заранее.

Если сформулировать грубо, вывод такой.

• Отправная точка для очистки дерева — Job Object
• Штатное завершение стоит разделять по типу: GUI / консоль / worker
• stdio нужно проектировать с учётом параллельного вычитывания и передачи EOF
• watchdog размещать вне объекта наблюдения и следить за ним через объекты ожидания и heartbeat, а не через опрос

CreateProcess и Process.Start сами по себе — лишь точка входа. На вероятность сбоя реально влияют то, где закреплена ответственность за завершение, и то, доведено ли вычитывание ввода-вывода до конца.

11. Источники

• Microsoft Learn, Job Objects
• Microsoft Learn, JOBOBJECT_BASIC_LIMIT_INFORMATION
• Microsoft Learn, UpdateProcThreadAttribute
• Microsoft Learn, InitializeProcThreadAttributeList
• Microsoft Learn, Inheritance (Processes and Threads)
• Microsoft Learn, CreateProcessW
• Microsoft Learn, Creating a Child Process with Redirected Input and Output
• Microsoft Learn, Pipe Handle Inheritance
• Microsoft Learn, Process.Kill
• Microsoft Learn, Process.CloseMainWindow
• Microsoft Learn, GenerateConsoleCtrlEvent
• Microsoft Learn, WaitForSingleObject
• Microsoft Learn, RegisterWaitForSingleObject
• Microsoft Learn, GetExitCodeProcess
• Microsoft Learn, JOBOBJECT_ASSOCIATE_COMPLETION_PORT

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Почему дочерний процесс остаётся работать после падения родительского?

Потому что ни дескриптор процесса, ни группа процессов сами по себе не содержат механизма восстановления дерева процессов при аварийном завершении родителя. Если нужно связать время жизни дерева дочерних процессов с жизнью родителя, отправная точка — Job Object. Если добавить JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE, все процессы, принадлежащие Job, завершаются в момент закрытия последнего дескриптора job — это позволяет привязать очистку к времени жизни родителя, включая его аварийное завершение.

Почему WaitForExit не возвращает управление?

Вероятнее всего, забились каналы (pipe) стандартного вывода и вывода ошибок. Каналы Windows не имеют бесконечного буфера, поэтому если дочерний процесс активно пишет в stderr, а родитель читает только stdout, дочерний процесс останавливается на записи, а родитель — в ожидании завершения. Базовое правило — читать stdout и stderr параллельно; реализация, при которой сначала полностью вычитывается один поток, а затем другой, легко приводит к зависанию. Кроме того, если не закрыть неиспользуемый конец канала, EOF не распространяется и условие завершения нарушается.

Достаточно ли одного Kill(entireProcessTree: true) в .NET?

Недостаточно. Это удобный API для явной остановки, но он не заменяет архитектуру, включающую автоматическое восстановление при падении родителя и штатное (graceful) завершение. Наименее подвержена сбоям трёхэтапная схема: запросить кооперативное завершение, подождать короткий тайм-аут и в конце принудительно завершить весь Job целиком. Способ кооперативного завершения зависит от типа дочернего процесса: для GUI-процесса — CloseMainWindow, для консольного — CREATE_NEW_PROCESS_GROUP и CTRL_BREAK_EVENT, для worker'а — протокол завершения через stdin или именованный канал.

Где должен располагаться процесс watchdog?

Важнее всего не помещать его в тот же Job, что и объект наблюдения. Если worker падает и его нужно перезапустить, а роль перезапуска гибнет вместе с ним, в этом нет смысла. При долговременно работающем worker'е стабильнее архитектура, при которой внешний процесс или служба watchdog создаёт отдельный Job для каждого нового поколения worker'а. Наблюдение за завершением стоит строить на объектах ожидания (wait handle), а не на опросе (polling); если нужно ещё и обнаруживать зависания, к этому добавляется проверка живости на уровне приложения — например, heartbeat.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.