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

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"