3

I am surprised that at least from Bash 4.4.19, Interactive Bash runs commands in a separate session, see following process list after I run sleep 8888:

PGID    PID       PPID
3150071 3150071  252603     -bash
3194323 3194323 3150071       sleep 8888

You can see the PGID of sleep does not equal to the bash, while its PPID does.

The test is done on Ubuntu Bionic.

Is there any documentation about this behavior change? or it has been acting this way since the beginning?

Running commands in a separate session means that the SIGHUP effects does not happen at all when bash exits, maybe this is why https://www.sobyte.net/post/2022-04/linux-nohup-setsid-disown/#about- says

In fact, on newer versions of bash, bash does not send SIGHUP commands to background programs. That means that any process running in the background ending with & will not be exited by the SIGHUP signal for terminal exit.

EDIT: I should use the term "process group" instead of "session".

Improve this question

1 Answer 1

Reset to default
5

Strictly speaking, interactive Bash with job control runs commands in separate process groups, not sessions:

   SESS    PGID     PID    PPID COMMAND
1082760 3784151 3784151 1082760 bash
1082760 3784782 3784782 3784151 sleep 120

As far as I remember, this has always been the case (at least, since Bash 2.0); I can’t find references to a relevant change in the Bash changelog. When job control is enabled, bash needs to be able to move a pipeline to the background when the user presses CtrlZ; to do that, it runs each pipeline in a different process group.

See the section on job control in the Bash manual. As described in the section on signals, Bash explicitly resends signals to relevant process groups; this also has always been the case.

Improve this answer
4
  • Thank you very much. I am under the impression that "in an interactive bash, starting a command in background without nohup or setsid will cause an issue that once bash exits, the background will also be killed by SIGHUP by default.", but now things seems changed, am I wrong?
    – osexp2000
    May 29 at 7:08
  • SigHUP does get passed to child processes (As do other signals that the process handles itself). You can use nohup to let any specific child ignore the signal.
    – Johan
    May 29 at 7:15
  • @osexp2000 that specific behaviour is controlled by the huponexit shopt flag, perhaps that’s what’s changed for you. Bear in mind that signals can be sent to shell-initiated processes by the kernel too, not just Bash; see this answer for some relevant discussion.
    – Stephen Kitt
    May 29 at 7:20
  • No wonder. It makes perfect sense. In my bash, shopt | grep huponexit outputs off. And the new progress group also makes perfect sense because that seems be the only way to attach/detach control terminal to/from the background job etc. Thank you, I am relieved.
    – osexp2000
    May 29 at 8:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .