Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Lew Pitcher Newsgroups: comp.unix.programmer Subject: Re: Why does getppid() still return old parent pid after setsid()? Date: Wed, 13 Nov 2024 15:00:53 -0000 (UTC) Organization: A noiseless patient Spider Lines: 69 Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Wed, 13 Nov 2024 16:00:56 +0100 (CET) Injection-Info: dont-email.me; posting-host="3a00e57054ce14f4847fa22ab39c4859"; logging-data="2372124"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+0JlEEZv1nD8Q6PnsUBZBKmZ4hA4mYCDA=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:JvSdO8Ryhmc868SI4nIKF8IAczQ= Bytes: 4575 On Wed, 13 Nov 2024 13:38:58 +0000, Richard Harnden wrote: > On 12/11/2024 12:15, Kenny McCormack wrote: >> In article , >> Lawrence D'Oliveiro wrote: >>> On Mon, 11 Nov 2024 10:02:45 -0000 (UTC), Muttley wrote: >>> >>>> can't help thinking they should be a single shot OS call to completely >>>> seperate the child from parent. >>> >>> I guess its not that important. >> >> It *is* "that important". And daemon(3) fills the role. >> >> However, it may be true that it doesn't fully fill it - and maybe that it >> should also do the "double fork". >> > > Should it be: parent fork, child setsid, child fork, grandchild exec > or: parent fork, child fork, grandchild setsid, grandchild exec With "parent fork, child fork, grandchild setsid, grandchild exec", while the grandchild's PPID is (or should be, sans race conditions) == 1 (init), it's SID (session ID) and PGID (process group ID) are now equal to its PID, putting the grandchild in a different session and process group than the original parent, and making the grandchild a session and group leader However, with "parent fork, child setsid, child fork, grandchild exec", while the grandchild's PPID is also (or should also be) == 1 (with the same caveats regarding race conditions), it's SID (session ID) and PGID (process group ID) are equal to its (real) parent. This also puts the grandchild in a different session and process group than the original parent, BUT, makes the grandchild a member of that session and group, instead of its leader. The difference is that the "parent fork, child fork, grandchild setsid, grandchild exec" sequence can still acquire a controlling terminal if it opens a terminal device WITHOUT the O_NOCTTY option. HOWEVER, the "parent fork, child setsid, child fork, grandchild exec" scenario CANNOT acquire a controlling terminal, no matter what options it opens a terminal device with. The "double fork" of the "double fork scenario" permits the child process to become a session and group leader (something that the parent process may not be able to do (if that parent process is already a process group leader, see setsid(2)). Because that child process is a session and group leader, it cannot "inherit" a controlling terminal; but it can open(2) a controlling terminal if it wishes. But, in the "double fork scenario", the child process fork(2)s the grandchild process immediately after setsid(2), then exits. This leaves the grandchild a) with a PPID of 1 (courtesy of the child process termination), b) a session ID which is not equal to its PID, c) a process group id which is not equal to its PID (so it is neither a session leader nor a process group leader), d) without a controlling terminal (courtesy of the setsid(2)), and e) without the ability to obtain a controlling terminal (because it is neither a session leader nor a process group leader). The grandchild can access files and devices, so it /has/ the ability to interact with the outside world, but on its own terms. The only way (highly simplified) the outside world can interact with the grandchild, though, is through root-generated signals, which the grandchild can handle with appropriate signal-handling logic. -- Lew Pitcher "In Skills We Trust"