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 <lew.pitcher@digitalfreehold.ca>
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: <vh2ev5$28cgs$1@dont-email.me>
References: <vgl8h1$385vs$1@dont-email.me>
	<vgn9q2$8mls$1@news.xmission.com> <vgsko5$u7pg$1@dont-email.me>
	<vgtr3i$15srv$2@dont-email.me> <vgvgt1$cnri$1@news.xmission.com>
	<vh2a5i$27jod$1@dont-email.me>
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 <vgtr3i$15srv$2@dont-email.me>,
>> Lawrence D'Oliveiro  <ldo@nz.invalid> 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"