Вопросы Теги

Новый родительский процесс, когда родительский процесс умирает

Я успешно установил openSUSE 11.1 PPC на своем PowerPC P5 9131-52A и скомпилированный qemu 1.1.1. У Вас должны быть zlib и бойкие 2.2.4 перед компиляцией. Затем:

#./configure --target-list="ppc-softmmu ppc64_softmmu"
# make 
# make install

Знайте, что после установки qemu необходимо удалить бойкие 2.2.4 выполнением, делают удаление в каталоге бойких 2.2.4, потому что иначе некоторые приложения могли бы повредиться.

Затем Вы можете qemu-system-ppc -vnc :0 -hda DEBIAN.img -cdrom DEBIAN.iso -boot d и соединитесь с:0 использованиями клиента VNC. Но действительно обратите внимание, что это очень медленно.

23
09.08.2014, 22:46
4 ответа

Перемещение моего комментария на страницу ответа..... Я не верю, что есть исключения.

Нашли это "иногда родительский процесс убивают до того, как убивают его ребенка". В этом случае "родитель всех процессов", init process, становится новым PPID (идентификатор родительского процесса). Иногда эти процессы называют процессом orphan". Источник

аналогично описан в блоге IBM : "Родитель умирает или погибает до того, как ребенок. В описанном выше сценарии процесс ребенка становится процессом сиротства (поскольку он потерял родителя). В Linux процесс init приходит на помощь процессам сирот и усыновляет их. Это означает, что после того, как ребенок потерял родителя, процесс init становится его новым родительским процессом"

.
5
27.01.2020, 19:41

Я так не думаю. Это всегда идет в процессе инициирования.

http://en.wikipedia.org/wiki/Orphan_process

3
27.01.2020, 19:41

Согласно странице руководства exit из спецификации Single UNIX®, версия 2:

Идентификатор родительского процесса для всех существующих дочерних процессов вызывающего процесса и процессов-зомби устанавливается для процесса Идентификатор системного процесса, зависящего от реализации. То есть эти процессы наследуются специальным системным процессом.

Для большинства вариантов Unix этим специальным процессом является init (PID 1).

Справочная страница Linux wait (2) подтверждает это:

Если родительский процесс завершается, его дочерние «зомби» (если есть) принимаются init (8), который автоматически выполняет ждать, чтобы удалить зомби.

FreeBSD wait (2) , NetBSD wait (2) , OpenBSD wait (2) и Mac OS X wait (2) страницы руководства также подтверждают это:

Если родительский процесс завершается, не дожидаясь завершения всех его дочерних процессов, оставшимся дочерним процессам присваивается идентификатор родительского процесса 1 (идентификатор процесса инициализации).

Справочная страница Oracle Solaris 11.1 wait (3C) также подтверждает это:

Если родительский процесс завершается, не дожидаясь завершения его дочерних процессов, устанавливается идентификатор родительского процесса для каждого дочернего процесса. в 1, при этом процесс инициализации наследует дочерние процессы; см. Intro (2) .

8
27.01.2020, 19:41

Три ответа, написанные в 2014 году, все говорят о том, что в Юнисах и в Linux процесс репарентируется на процесс #1 без исключений. Три неправильных ответа. ☺

Как говорит SUS, процитированный в одном из других ответов здесь, чтобы я не цитировал его снова, родительский процесс детей-сирот установлен на процесс , определяемый реализацией . Кристиан Сьюпиту (Cristian Ciupitu) прав, обращаясь к документации по Linux, чтобы узнать, что определяет эта реализация. Но его вводит в заблуждение эта документация, которая непоследовательна и неактуальна.

За два года до написания этих трех ответов, и быстро приближаясь к трем годам назад, во время первого написания этого ответа, ядро Linux изменилось. Разработчики systemd добавили возможность для процессов устанавливать себя в качестве "поддокументов". Начиная с Linux 3.4 процессы могут выдавать системный вызов prctl() с опцией PR_SET_CHILD_SUBREAPER, в результате чего они, а не процесс #1, станут родителями любого из своих осиротевших процессов-потомков. man-страница для prctl() является актуальной, но другие man-страницы не были обновлены и сделаны согласованными.

В версии 10.2 FreeBSD получила такую же возможность, расширив существующую систему вызова procctl() опциями PROC_REAP_ACQUIRE и PROC_REAP_RELEASE. Он перенял этот механизм из BSD DragonFly, который получил его в версии 4.2, первоначально названной reapctl(), но при разработке переименованной в procctl().

Таким образом, есть и исключения, и достаточно заметные: В Linux, FreeBSD/PC-BSD и DragonFly BSD родительский процесс осиротевших детей устанавливается на ближайший процесс-предшественник ребенка, помеченный как поддокументатор, или процесс #1, если поддокументатор-предшественник отсутствует. Различные утилиты наблюдения за демонами - в том числе systemd (разработчики которого в первую очередь поместили это в ядро Linux), upstart и nosh service-manager - уже используют это.

Если такой даемонный супервизор не является процессом #1 и порождает такой сервис, как интерактивный сеанс входа в систему, и в этом сеансе выполняется (совершенно безрассудный) трюк попытки "даемонизировать" с помощью double-fork()ing, то чей-то процесс окажется дочерним по отношению к даемонному супервизору, а не по отношению к процессу #1. Ожидание возможности напрямую порождать демонов из сеансов входа в систему, конечно же, является фундаментальной ошибкой. Но это другой ответ.

Дальнейшее чтение

62
27.01.2020, 19:41

Теги

Похожие вопросы