В чем причина создания двойного форка при создании демона?

Я пытаюсь создать демон в Python. Я нашел следующий вопрос , в котором есть несколько полезных ресурсов, за которыми я сейчас следую, но мне любопытно, зачем нужна двойная вилка. Я покопался в гугле и нашел множество ресурсов, объявляющих, что это необходимо, но не зачем.

Некоторые упоминают, что это предотвращает приобретение демоном управляющего терминала. Как бы это сделать без второй развилки? Каковы последствия?

Глядя на код, указанный в вопросе, обоснование:

Раздвиньте второго ребенка и немедленно выйдите, чтобы предотвратить появление зомби. Это приводит к тому, что второй дочерний процесс становится осиротевшим, что делает процесс init ответственным за его очистку. И, поскольку первый дочерний объект является лидером сеанса без управляющего терминала, он может приобрести его, открыв терминал в будущем (системы на основе System V). Этот второй ответвление гарантирует, что дочерний элемент больше не является лидером сеанса, предотвращая получение демоном управляющего терминала.

Таким образом, он должен гарантировать, что демон заново переименован в init (на случай, если процесс, запускающий демона, является долгоживущим), и исключает любые шансы демона на повторный захват управляющего tty. Так что, если ни один из этих случаев не применим, то одной вилки должно быть достаточно. " Сетевое программирование Unix - Стивенс " имеет хороший раздел на эту тему.

Я пытался понять двойную вилку и наткнулся на этот вопрос здесь. После долгих исследований это то, что я понял. Надеюсь, это поможет прояснить ситуацию для тех, у кого такой же вопрос.

В Unix каждый процесс принадлежит группе, которая, в свою очередь, принадлежит сеансу. Вот иерархия ...

Сеанс (SID) → Группа процессов (PGID) → Процесс (PID)

Первый процесс в группе процессов становится лидером группы процессов, а первый процесс в сеансе становится лидером сеанса. С каждым сеансом может быть связан один TTY. Только лидер сеанса может взять под контроль TTY. Для того, чтобы процесс был по-настоящему демонизирован (запущен в фоновом режиме), мы должны убедиться, что лидер сеанса убит, чтобы исключить возможность того, что сеанс когда-либо получит контроль над TTY.

Я запустил программу-демон Сандера Маречала на Python с этого сайта на моем Ubuntu. Вот результаты с моими комментариями.

1. `Parent`    = PID: 28084, PGID: 28084, SID: 28046
2. `Fork#1`    = PID: 28085, PGID: 28084, SID: 28046
3. `Decouple#1`= PID: 28085, PGID: 28085, SID: 28085
4. `Fork#2`    = PID: 28086, PGID: 28085, SID: 28085

Обратите внимание, что процесс является лидером сеанса после Decouple#1, потому что это PID = SID. Это все еще может взять под контроль TTY.

Обратите внимание, что Fork#2больше не является лидером сессии PID != SID. Этот процесс никогда не может взять под контроль TTY. Истинно демонизирован.

Лично я нахожу терминологическую форк-двойку непонятной. Лучшей идиомой может быть вилка-развязка-вилка.

Дополнительные ссылки, представляющие интерес:

• Процессы Unix - http://www.win.tue.nl/~aeb/linux/lk/lk-10.html

Строго говоря, двойная вилка не имеет ничего общего с повторным воспитанием демона как потомка init. Все, что необходимо для повторного воспитания ребенка, это то, что родитель должен выйти. Это может быть сделано только с одной вилкой. Кроме того, двойное разветвление само по себе не переопределяет процесс демона init; родитель демона должен выйти. Другими словами, родитель всегда выходит, когда разветвляет правильного демона, чтобы процесс демона был переназначен init.

Так почему двойная вилка? POSIX.1-2008 Раздел 11.1.3, « Терминал управления », содержит ответ (выделение добавлено):

Управляющий терминал для сеанса назначается руководителем сеанса в зависимости от реализации. Если лидер сеанса не имеет управляющего терминала и открывает файл терминального устройства, который еще не связан с сеансом, без использования O_NOCTTYопции (см. open()), То определяется, будет ли реализация управляющим терминалом лидера сеанса. Если процесс, который не является лидером сеанса, открывает файл терминала или используется O_NOCTTYопция open(), то этот терминал не должен становиться управляющим терминалом вызывающего процесса .

Это говорит нам о том, что если процесс-демон делает что-то вроде этого ...

int fd = open("/dev/console", O_RDWR);

... тогда процесс-демон может быть выбран в /dev/consoleкачестве управляющего терминала в зависимости от того, является ли процесс-демон лидером сеанса, и в зависимости от реализации системы. Программа может гарантировать, что вышеуказанный вызов не получит управляющий терминал, если программа сначала гарантирует, что он не является лидером сеанса.

Обычно при запуске демона setsidвызывается (от дочернего процесса после вызова fork), чтобы отделить демон от его управляющего терминала. Однако вызов setsidтакже означает, что вызывающий процесс будет лидером сеанса нового сеанса, что оставляет открытой возможность того, что демон может повторно захватить управляющий терминал. Метод двойного разветвления гарантирует, что процесс-демон не является лидером сеанса, что затем гарантирует, что вызов open, как в примере выше, не приведет к тому, что процесс-демон повторно запросит управляющий терминал.

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

Взято из Bad CTK :

«В некоторых разновидностях Unix вы вынуждены делать двойную форк при запуске, чтобы перейти в режим демона. Это потому, что одноразовое разветвление не гарантирует отсоединение от управляющего терминала».

Согласно «Расширенному программированию в среде Unix» Стивенса и Раго, второй ответвление является скорее рекомендацией, и оно сделано для того, чтобы гарантировать, что демон не получит управляющий терминал в системах на основе System V.

Одна из причин заключается в том, что родительский процесс может немедленно поднять wait_pid () для потомка, а затем забыть об этом. Когда потом умирает внучка, его родителем является init, и он будет ждать () этого - и выводит его из состояния зомби.

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

Вызов daemon () имеет родительский вызов _exit () в случае успеха. Первоначальная мотивация, возможно, заключалась в том, чтобы позволить родителю выполнять дополнительную работу, пока ребенок демонизирует.

Это также может быть основано на ошибочном убеждении, что это необходимо для того, чтобы у демона не было родительского процесса и он был переименован в init - но это произойдет в любом случае, когда родитель умирает в случае с одним форком.

Так что я полагаю, что в конце концов все сводится к традиции - достаточно одной развилки, если родитель все равно умрет в коротком порядке.

Достойное обсуждение этого, кажется, находится на http://www.developerweb.net/forum/showthread.php?t=3025

Цитирую Млампкина оттуда:

... думать о вызове setsid () как о "новом" способе выполнения вещи (отсоединении от терминала) и о вызове [second] fork () после него как о избыточности для работы с SVr4 ...

Это может быть легче понять следующим образом:

• Первый форк и setsid создадут новый сеанс (но идентификатор процесса == идентификатор сеанса).
• Вторая ветвь удостоверяется, что идентификатор процесса! = Идентификатор сессии.