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

On Fri, 08 Nov 2024 14:51:13 +0000, Muttley 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 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.

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;
}

HTH

--
Lew Pitcher
"In Skills We Trust"