3

In The Linux Programming Interface:

SIGHUP is generated when a process group becomes orphaned.

In an interactive bash process,

$ ( sleep 123 &)

will first forks a subshell, and the subshell then forks to execute sleep 123 &. The subshell exits immediately without waiting sleep 123 to finish because of &. At that time,

  • is the sleep process orphaned? (I think yes, Figure 34.3)

  • is SIGHUP sent to the sleep process because it becomes orphaned? (I guess it is, by the quote)

  • why doesn't the sleep process terminate because SIGHUP is sent to it? (I am not sure)

Thanks.

I also have similar question when create a daemon process by first forking a child process and then the child process forking a grandchild and exiting immediately. The grandchild becomes orphaned and isn't SIGHUP sent to it, making it terminate?

Tim
  • 98,580
  • 191
  • 570
  • 977

1 Answers1

2

From The Open Group Base Specifications Issue 7, 2018 edition, System Interfaces, under _exit:

  • If the process is a controlling process, the SIGHUP signal shall be sent to each process in the foreground process group of the controlling terminal belonging to the calling process.

  • If the process is a controlling process, the controlling terminal associated with the session shall be disassociated from the session, allowing it to be acquired by a new controlling process.

  • If the exit of the process causes a process group to become orphaned, and if any member of the newly-orphaned process group is stopped, then a SIGHUP signal followed by a SIGCONT signal shall be sent to each process in the newly-orphaned process group.

Community
  • 1
AlexP
  • 10,217
  • 32
  • 41
  • 1
    Thanks. I upvoted your reply, but (1) In an interactive shell, when you run a command, you start a new process group different from the process group where the original shell belong. (2) in the example I gave, `(sleep 123 &)`, `sleep 123 &` process becomes the only process in its own process group, and it has been reparented to some other process outside its process session, so it and its group are both orphaned. – Tim Nov 27 '18 at 13:29
  • Take a look at Figure 34.3 at https://books.google.com/books?id=2SAQAQAAQBAJ&lpg=PA726&ots=qRt089CDsy&dq=In%20Figure%2034-3%2C%20the%20process%20group%20containingthe%20child%20is%20orphaned%20because%20the%20child%20is%20in%20a%20process%20group%20on%20its%20own%20and%20its%20par-ent%20(init)%20is%20in%20a%20different%20session&pg=PA726#v=onepage&q&f=false – Tim Nov 27 '18 at 13:33
  • @Tim: The figure presupposes that the parent is a group leader; maybe the author could have explained this in more detail. Processes don't become group leaders unless they call `setsid()` or `setpgid()`; a process is never made a group leader automatically -- it has to say that it wants to be a group (or session) leader. That's why all processes started from a user's interactive shell get SIGHUP when that shell terminates. – AlexP Nov 27 '18 at 13:59
  • 1
    "In most job-control shells, this function setpgid() is called after a fork to have the parent set the process group ID of the child, and to have the child set its own process group ID. One of these calls is redundant, but by doing both, we are guaranteed that the child is placed into its own process group before either process assumes that this has happened. If we didn’t do this, we would have a race condition, since the child’s process group membership would depend on which process executes first" See p294 of APUE 3ed. – Tim Nov 27 '18 at 14:03
  • @Tim: You are right and I am outdated; I did not take job control into account. – AlexP Nov 27 '18 at 14:05
  • Could we come back to my question about SIGHUP? – Tim Nov 27 '18 at 14:06
  • @Tim: It's on the page you linked: *a process group is not orphaned if at least one of its members has a parent in a different process group but in the same session*. – AlexP Nov 27 '18 at 14:09
  • In my earlier comment, I have said why I think it is orphaned. https://unix.stackexchange.com/questions/484344/is-sighup-sent-to-this-orphaned-process-and-why-doesnt-it-terminate#comment887747_484373 – Tim Nov 27 '18 at 14:10
  • @Tim: Found chapter and verse in POSIX System Interfaces. – AlexP Nov 27 '18 at 14:26
  • Thanks. I am still wondering if SIGHUP is sent to the orphaned process `sleep 123`, and why doesn't it terminate? – Tim Nov 27 '18 at 14:46
  • 1
    @Tim: Since no member of the process group is stopped (= in the stopped state, having received SIGTSTP, SIGSTOP, SIGTTIN, or SIGTTOU), no signal is generated. – AlexP Nov 27 '18 at 19:50
  • Thanks. Could you show some examples, (1) for "If the exit of the process causes a process group to become orphaned, and if **any** member of the newly-orphaned process group is stopped, then a SIGHUP signal followed by a SIGCONT signal shall be sent to each process in the newly-orphaned process group", and (2) for "If the exit of the process causes a process group to become orphaned, and if **no** member of the newly-orphaned process group is stopped"? – Tim Dec 22 '18 at 06:05
  • Let me clarify. In `( sleep 123 &)`, the `sleep 123` will continue running. How can I make it stopped when its parent subshell exits? – Tim Dec 22 '18 at 16:36
  • If you are interested, I'd appreciate if you could also see https://unix.stackexchange.com/questions/490494/does-sending-sighup-to-a-process-group-that-becomes-orphaned-and-contains-a-stop and https://unix.stackexchange.com/questions/490495/how-can-i-make-a-child-process-of-a-subshell-stopped-before-the-subshell-exits – Tim Dec 22 '18 at 17:05
  • Compare `( ps -o pid,ppid,pgrp,state,args ); sleep 2` with `( ps -o pid,ppid,pgrp,state,args & ); sleep 2`. And the answer at https://unix.stackexchange.com/questions/490495/how-can-i-make-a-child-process-of-a-subshell-stopped-before-the-subshell-exits is perfect. – AlexP Dec 22 '18 at 19:41