Re: Why does getppid() still return old parent pid after setsid()?

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"