Хабрахабр

[Перевод] fork() может глюкануть: это важно

Эх, fork(). Одни процессы порождают другие. Кажется, у меня есть история об этом.

Форк может глюкануть. Понимаете? В самое деле, понимаете? Это очень серьёзно. Форк может глюкануть. Так же, как и malloc. Нечасто, но когда такое происходит, нельзя просто взять и игнорировать это. Вы должны что-то предпринять в таком случае.

Похоже, всем известно, что fork возвращает дочернему процессу 0, а родителю некоторое положительное число — pid ребенка. Он выдаёт этот номер, который используется позже.

Угадайте, что происходит, когда вы не проверяете ответ на ошибку? Да, вы возьмёте "-1" (глюк форка) как pid.
Это только начало. Настоящая боль начинается позже, когда приходит время послать сигнал. Может, вы захотите закрыть дочерний процесс.

Вы делаете kill(pid, signal). Например, kill(pid, 9).

Что происходит, когда когда pid равен -1? Это действительно важно знать. Реально важно.



Здесь я вставлю со справочной страницы kill(2) со своего Linux.

Если pid равен -1, то sig отправляется каждому процессу, для которого вызывающий процесс имеет разрешение на отправку сигналов, за исключением процесса 1(init)...

Видите? Убить pid -1 эквивалентно уничтожению всех остальных процессов. Если вы рут, то на этом всё закончилось. Остались вы и init. Всё остальное ушло, ушло, ушло.

У вас есть код, который управляет процессами? Когда-нибудь находили машину полностью мертвой, за исключением текстовой консоли getty/login (которых перезапуксает init, естественно) и менеджера процессов? Наверное, винили в этом oomkiller в ядре?

Возможно, он не виноват. Лучше проверьте, что вы не запустили kill(-1).

В Unix достаточно ловушек и медвежьих капканов на любой вкус.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»