Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Richard Harnden <richard.nospam@gmail.invalid>
Newsgroups: comp.unix.programmer
Subject: Re: Why does getppid() still return old parent pid after setsid()?
Date: Wed, 13 Nov 2024 17:23:26 +0000
Organization: A noiseless patient Spider
Lines: 70
Message-ID: <vh2nae$2aai0$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>
 <vh2ev5$28cgs$1@dont-email.me>
Reply-To: nospam.harnden@invalid.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 13 Nov 2024 18:23:27 +0100 (CET)
Injection-Info: dont-email.me; posting-host="87c6b61cde6c0498c083f38248d2565a";
	logging-data="2435648"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19asl2ki6CvIJrpkOKD1Tj7IENmS33Dmag="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:XDrutsS/sKCLup2iOTQ7lKYCaXc=
Content-Language: en-GB
In-Reply-To: <vh2ev5$28cgs$1@dont-email.me>
Bytes: 4761

On 13/11/2024 15:00, Lew Pitcher wrote:
> 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.
> 
> 

Thanks very much.