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

[M***@DastartdlyHQ.org]

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?

int main()
{
printf("Parent pid %d\n",getpid());
switch(fork())
{
case -1:
perror("fork");
return 0;
case 0:
// child
break;
default:
// Parent
sleep(1);
return 0;
}

setsid();
printf("Child parent = %d\n",getppid());
return 0;
}

[Lew Pitcher]

Post by M***@DastartdlyHQ.org
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 cant claim to be an expert on this, but my understanding of the situation
is this:

Each process maintains a /number/ of relationships with other processes,
/one/ of which is ppid (parent PID). setsid() only affects the "process group"
and "session" relationships, and not the "parent" relationship.

On my system, credentials(7) says:
Sessions and process groups are abstractions devised to support shell
job control. A process group (sometimes called a "job") is a collec-
tion of processes that share the same process group ID; the shell cre-
ates a new process group for the process(es) used to execute single
command or pipeline (e.g., the two processes created to execute the
command "ls | wc" are placed in the same process group). A process's
group membership can be set using setpgid(2). The process whose
process ID is the same as its process group ID is the process group
leader for that group.

A session is a collection of processes that share the same session ID.
All of the members of a process group also have the same session ID
(i.e., all of the members of a process group always belong to the same
session, so that sessions and process groups form a strict two-level
hierarchy of processes.) A new session is created when a process calls
setsid(2), which creates a new session whose session ID is the same as
the PID of the process that called setsid(2). The creator of the ses-
sion is called the session leader.

All of the processes in a session share a controlling terminal. The
controlling terminal is established when the session leader first opens
a terminal (unless the O_NOCTTY flag is specified when calling
open(2)). A terminal may be the controlling terminal of at most one
session.

At most one of the jobs in a session may be the foreground job; other
jobs in the session are background jobs. Only the foreground job may
read from the terminal; when a process in the background attempts to
read from the terminal, its process group is sent a SIGTTIN signal,
which suspends the job. If the TOSTOP flag has been set for the termi-
nal (see termios(3)), then only the foreground job may write to the
terminal; writes from background job cause a SIGTTOU signal to be gen-
erated, which suspends the job. When terminal keys that generate a
signal (such as the interrupt key, normally control-C) are pressed, the
signal is sent to the processes in the foreground job.

So, while setsid(2) "creates a session and sets the process group ID" for a
process, it does not change the process' parent PID.

Post by M***@DastartdlyHQ.org
int main()
{
printf("Parent pid %d\n",getpid());
switch(fork())
{
perror("fork");
return 0;
// child
break;
// Parent
sleep(1);
return 0;
}
setsid();
printf("Child parent = %d\n",getppid());
return 0;
}

HTH

[Lawrence D'Oliveiro]

Post by Lew Pitcher
So, while setsid(2) "creates a session and sets the process group ID"
for a process, it does not change the process' parent PID.

It is possible for the parent process to terminate before the child.
The child is then said to be “orphaned”. From this point, normally
getppid() will return 1, the PID of the init process.

However, on Linux, it is possible to specify an alternative “child
subreaper” process, via prctl()
<https://manpages.debian.org/bookworm/manpages-dev/prctl.2.en.html>.
getppid() will then return the ID of this process.

[Scott Lurndal]

Post by M***@DastartdlyHQ.org
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?

You only want the child to issue setsid.

Post by M***@DastartdlyHQ.org
int main()
{
printf("Parent pid %d\n",getpid());
switch(fork())
{
perror("fork");
return 0;

setsid();

Post by M***@DastartdlyHQ.org
// child
break;
// Parent
sleep(1);
return 0;
}
printf("Child parent = %d\n",getppid());
return 0;
}

pid = fork();
if (pid == (pid_t)-1) {
pfmt(stderr, MM_ERROR, failed, "fork", Strerror(errno));
goto dead;
}
if (pid == 0) {
sigchild();
#ifdef SIGTSTP
sigset(SIGTSTP, SIG_IGN);
sigset(SIGTTIN, SIG_IGN);
sigset(SIGTTOU, SIG_IGN);
#endif
signal(SIGHUP,SIG_IGN);
signal(SIGINT,SIG_IGN);
signal(SIGQUIT,SIG_IGN);
#ifdef preSVr4 /* block all tty generated signals from affecting our mailer */
setpgrp();
#else
setsid();
#endif
s = fileno(mtf);
for (i = 3; i < 32; i++)
if (i != s)
close(i);
close(0);
dup(s);
close(s);
if ((deliver = value("sendmail")) == NOSTR)
deliver = MAIL;
execvp(safeexpand(deliver), namelist);
pfmt(stderr, MM_ERROR, errmsg, deliver, Strerror(errno));
fflush(stderr);
_exit(1);
}

[Kenny McCormack]

Post by M***@DastartdlyHQ.org
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?

I'm not saying that to be snarky (seriously, I'm not!). I am genuinely
curious as to why you are curious. If this is a solely a question of
academic curiosity, then the answer is "because that's the way it is". As
far as I know, in classic Unix, the only way for a process to get
"re-parented" is to have the parent die. Of course, as others have noted,
under Linux, there is also the re-parenting "prctl".

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()).

BTW, note that "total isolation" (in your words, "completely detach") is
actually somewhat difficult to achieve and care must be taken to do it
right. Among other things, if you have any terminals open (the usual
stdin/stdout/stderr), then you still have a connection to those terminals
and may receive signals therefrom (e.g., if a user hits ^C on that terminal
or if the terminal is terminated). "sshfs", in particular, is vulnerable
to this problem; unless you take special care, sshfs will terminate if the
shell (terminal window) from which it was launched is exited.

In fact, it is somewhat surprising how many common ordinary day-to-day
programs there are that still do things like this. And by "do things like
this", I mean fail to daemonize correctly.

[Lew Pitcher]

Post by Kenny McCormack

Post by M***@DastartdlyHQ.org
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]

Post by Kenny McCormack
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]

Post by Lew Pitcher

Post by Kenny McCormack

Post by M***@DastartdlyHQ.org
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]

Post by Kenny McCormack
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.

I have to correct myself here. According to the BUGS section of the
glibc daemon(3) manpage:
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.

Post by Lew Pitcher
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

[M***@DastartdlyHQ.org]

On Sat, 9 Nov 2024 09:25:22 -0000 (UTC)

Post by Kenny McCormack

Post by M***@DastartdlyHQ.org
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.

Post by Kenny McCormack
under Linux, there is also the re-parenting "prctl".

I didn't know that, thanks.

[Lew Pitcher]

Post by M***@DastartdlyHQ.org
On Sat, 9 Nov 2024 09:25:22 -0000 (UTC)

Post by Kenny McCormack

Post by M***@DastartdlyHQ.org
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]

[Scott Lurndal]

Post by Lew Pitcher

Post by M***@DastartdlyHQ.org
On Sat, 9 Nov 2024 09:25:22 -0000 (UTC)

Post by Kenny McCormack

Post by M***@DastartdlyHQ.org
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."

That's why POSIX has the 'O_NOCTTY' flag for open.

[Lawrence D'Oliveiro]

Post by M***@DastartdlyHQ.org
can't help thinking they should be a single shot OS call to completely
seperate the child from parent.

I guess it’s not that important.

[Kenny McCormack]

Post by M***@DastartdlyHQ.org
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".

[Richard Harnden]

Post by Kenny McCormack

Post by M***@DastartdlyHQ.org
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

?

[Lew Pitcher]

Post by Richard Harnden

Post by Kenny McCormack

Post by M***@DastartdlyHQ.org
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.

[Richard Harnden]

Post by Lew Pitcher

Post by Richard Harnden

Post by Kenny McCormack

Post by M***@DastartdlyHQ.org
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.

[Lew Pitcher]

On Sat, 09 Nov 2024 09:25:22 +0000, Kenny McCormack wrote:
[snip]

Post by Kenny McCormack
As
far as I know, in classic Unix, the only way for a process to get
"re-parented" is to have the parent die. Of course, as others have noted,
under Linux, there is also the re-parenting "prctl".

Kenny, could you elaborate on the use of prctl() to "reparent" a process?
I've not seen examples of how to do this, and the prctl(2) manpage doesn't
explicitly indicate the options necessary.

I don't see any option that controls or modifies a process PPID. The only
prctl(2) options that I can see relating to "reparenting" are the
PR_SET_CHILD_SUBREAPER and PR_GET_CHILD_SUBREAPER options that
seem to govern who gets SIGCHLD on the child's death. Is this what you
mean by "reparenting"?

[snip]

[Kenny McCormack]

In article <vgtdm4$11fog$***@dont-email.me>,
Lew Pitcher <***@digitalfreehold.ca> wrote:
...

Post by Lew Pitcher
Kenny, could you elaborate on the use of prctl() to "reparent" a process?
I've not seen examples of how to do this, and the prctl(2) manpage doesn't
explicitly indicate the options necessary.
I don't see any option that controls or modifies a process PPID. The only
prctl(2) options that I can see relating to "reparenting" are the
PR_SET_CHILD_SUBREAPER and PR_GET_CHILD_SUBREAPER options that
seem to govern who gets SIGCHLD on the child's death. Is this what you
mean by "reparenting"?

Yes, that's it. The man page text even includes the word 'reparented'.

Note; I've never actually used this call, but I can imagine situations
where it could be used. The man page seems pretty clear as to what it does.

[Rainer Weikusat]

Post by M***@DastartdlyHQ.org
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?

A session is a set of processes associated with a particular controlling
terminal, namely, that of the session leader (or no controlling terminal
if the session leader doesn't have one). setsid creates an unassociated
new session lead by the process which called it. It has no effect on
parent/ child relationships of processes.

[Geoff Clare]

Post by M***@DastartdlyHQ.org
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?

As others have pointed out, you have misunderstood, but I don't
think anyone has quoted a relevant bit of POSIX in the definition
of "Parent Process ID" (XBD 3.253 in POSIX.1-2024):

The parent process ID of a process is the process ID of its
creator, for the lifetime of the creator. After the creator's
lifetime has ended, the parent process ID is the process ID of an
implementation-defined system process.

[M***@DastartdlyHQ.org]

On Tue, 12 Nov 2024 13:39:25 +0000

Post by Geoff Clare

Post by M***@DastartdlyHQ.org
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?

As others have pointed out, you have misunderstood, but I don't
think anyone has quoted a relevant bit of POSIX in the definition
The parent process ID of a process is the process ID of its
creator, for the lifetime of the creator. After the creator's
lifetime has ended, the parent process ID is the process ID of an
implementation-defined system process.

Fair enough. So reparenting can't happen so long as the parent exists no matter
what the child does.

I could envisage scenarios where the child process being able to reparent
itself - given correct permissions - could be useful. Wonder if any OS's
implement that?

[Kaz Kylheku]

Post by M***@DastartdlyHQ.org
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?

No; it's because you put a 1 second delay into the parent to keep it
alive, whereas the child calls getppid() without any such timed
scheduling delay.

Because 1 second is an eternity, you've practically guaranteed that the
child will get the original parent pid. The only thing that would make
it air tight would be if the parent waited for the child's termination
instead of sleeping.

setsid has to do with the TTY session, and manipulates the group ID.
If you read descriptions of it carefully, you will see that it has
nothing to do with detaching from a parent process.

To detach from a parent process, do a double fork to create a
grandchild. Have the child quit. Then the grandchild will be orphaned
and reparented to some process (typically PID 1). The timing of
that is "racy"; it has to do with when the intermediate child
terminates, until which time, the grandchild has that process as its
parent PID.

[M***@DastartdlyHQ.org]

On Tue, 12 Nov 2024 21:24:52 -0000 (UTC)

Post by Kaz Kylheku

Post by M***@DastartdlyHQ.org
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?

No; it's because you put a 1 second delay into the parent to keep it
alive, whereas the child calls getppid() without any such timed
scheduling delay.

True, I fixed it soon after, should have been the child that executed it.
But it doesn't make any difference but now I know why.