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? Commented May 29, 2023 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. Commented May 29, 2023 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. Commented May 29, 2023 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. Commented May 29, 2023 at 8:03

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.