Зачем вызывать setsid после fork?

Question

Это вопрос об ответе на ответ Praveen Gollakota другой вопрос (это способ, которым я должен обойти права на комментарии?).

Его ответ на вопрос о том, почему ответвление дважды, по сути, означает, что разветвленный процесс не является лидером сеанса и, следовательно, не может получить tty. Он приводит этот пример процесса разветвления и показывает, что второй дочерний элемент не является лидером сеанса (SID после второго ответвления не является PID второго дочернего элемента).

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

Тем не менее, вы также можете увидеть здесь, что после первого форка и до шага "развязки" (я предполагаю, что это вызов setsid()) ребенок не является лидером сессии. Поэтому мой вопрос, зачем звонить setsid()? Почему бы не разветвиться и выйти?

Я предполагаю, что это как-то связано с тем, что лидером сеанса является управляющий терминал (или другой дедушка). Таким образом, последующий вопрос будет таким: что происходит с процессом, из которого выходит лидер группы, но чей лидер сессии еще жив?

Answer 1

1. `Parent`    = PID: 28084, PGID: 28084, SID: 28046

На этом этапе программа имеет управляющий терминал.

2. `Fork#1`    = PID: 28085, PGID: 28084, SID: 28046

На этом этапе программа все еще имеет управляющий терминал. Если родитель вышел, этот ребенок будет принадлежать к оставленной группе процессов. Оно может setpgid() в другую группу процессов в том же сеансе.

3. `Decouple#1`= PID: 28085, PGID: 28085, SID: 28085

Сейчас программа находится в другом сеансе и не может setpgid() переключиться на группу процессов в исходном сеансе.

4. `Fork#2`    = PID: 28086, PGID: 28085, SID: 28085

Reparent to init,