On Sun 10 Jan 2021 at 16:57:43 -0500, Mouse wrote: > That made no sense to me either. Neither does the test that forbids > process group leaders from setsid()ing. That can at least partially be explained, at least if one rephrases it first as "session leaders are forbidden to setsid()". A process is a session leader if its session id is equal to its process id. This is similar for process groups. Now setsid() creates a new session AND a new process group, and the current process is to be the leader of both. A process that is already a session|group leader of any session|group cannot therefore become the leader of a new session|group. This reasoning works for the POSIX session, which has session ids. The old BSD did not have session ids so part of the reasoning doesn't work directly. But there may be still a prohibition there if a session leader is by necessity also always a process group leader. This indeed seems to be the case, since setsid() makes it so, and a group leader cannot give up its leadership. Now if the setsid() limitation was designed first, and then the ids were designed this way... or the ids were first, and the setsid() limitation was deemed acceptable... that we will have to guess. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
Attachment:
signature.asc
Description: PGP signature