Sujet : Re: Why does getppid() still return old parent pid after setsid()?
De : lew.pitcher (at) *nospam* digitalfreehold.ca (Lew Pitcher)
Groupes : comp.unix.programmerDate : 09. Nov 2024, 16:49:33
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vgo0ad$3r9kp$1@dont-email.me>
References : 1 2
User-Agent : Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2)
On Sat, 09 Nov 2024 09:25:22 +0000, Kenny McCormack wrote:
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?
[snip]
The usual method for ensuring that a process *does* have getppid() == 1 is
the classic "double fork". The parent forks(), the child then forks() and
exits. The grandchild then does the work (either directly or via exec()).
Some systems (notably BSD) provide a daemon(3) function that does this. GNU
glibc provides this function by default (feature test macro _DEFAULT_SOURCE)
since glibc 2.21. W. Richard Stevens discusses the details in chapter 13
of "Advanced Programming in the Unix Environment" (aka the "APUE" book).
[snip]
HTH
-- Lew Pitcher"In Skills We Trust"