Path: 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: Mon, 11 Nov 2024 15:20:25 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 36
Message-ID: <vgt7bp$11fog$1@dont-email.me>
References: <vgl8h1$385vs$1@dont-email.me>
	<vgn9q2$8mls$1@news.xmission.com> <vgsko5$u7pg$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 11 Nov 2024 16:20:25 +0100 (CET)
Injection-Info: dont-email.me; posting-host="090d5a8025b43e616f11aef0313ce297";
	logging-data="1097488"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18uNSLgKPyx4KlSa5P4mIdXykGwumwWtko="
User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508
 git://git.gnome.org/pan2)
Cancel-Lock: sha1:P2t5to52yxQLitBNlxCGKyZczG8=

On Mon, 11 Nov 2024 10:02:45 +0000, Muttley wrote:

> On Sat, 9 Nov 2024 09:25:22 -0000 (UTC)
> gazelle@shell.xmission.com (Kenny McCormack) boring babbled:
>>In article <vgl8h1$385vs$1@dont-email.me>,  <Muttley@DastartdlyHQ.org> wrote:
>>>I've tried this code on both MacOS and Linux yet the child process getppid()
>>>still returns its original parent process instead of "1" for init which is 
>>>what I'd expect. Isn't setsid() supposed to completely detach the child or
>>>have I misunderstood?
>>
>>I suppose the obvious question at this point is: Why do you care?  What's
>>the underlying issue?
> 
> Just curiousity mainly. I did setsid() and ignored SIGCLD so I wouldn't get
> zombie processes but noticed that getppid() didn't return 1. I'd forgotten
> about double fork to be fair - I need to re-read Stevens at some point! - but
> can't help thinking they should be a single shot OS call to completely
> seperate the child from parent. Yes, daemon() will do it as a single function
> call but I imagine that just does a double fork underneath anyway.

According to daemon(3) from glibc, the glibc version (common on Linux systems)
does not perform a double fork(2). Specifically,
  "The GNU C library implementation of this function was taken  from  BSD,
   and  does  not  employ  the  double-fork technique (i.e., fork(2), set-
   sid(2), fork(2)) that is necessary to ensure that the resulting  daemon
   process  is  not  a session leader.  Instead, the resulting daemon 
   session leader.  On systems  that  follow  System  V  semantics  (e.g.,
   Linux),  this  means  that  if  the daemon opens a terminal that is not
   already a controlling terminal for another session, then that  terminal
   will inadvertently become the controlling terminal for the daemon."

[snip]

-- 
Lew Pitcher
"In Skills We Trust"