Hello!
I've just started to read System V Interface Definition and came across this entry: "Background Process Group
A background process group is any process group that is a member of a session
which has established a connection with a controlling terminal that is not in the
foreground process group."
I'd never known that there is a session between processes and the terminal, how come is this?
This is how UNIX handles background processes. And who responds to a terminal keypress. There is also a setsid() system call that is used in controlling all of this. These groups are usually called sessions.
In compliant shells, you have commands to work within this context. Like fg and job , which are part of the shell and do not run as child processes. They are linked directly into the shell, unlike most commands - e.g., grep and ls
1 Like
You probably know roughly what it's doing - foreground and background processes, SIGINT on ctrl-c, any background process clutter cleaned up with SIGHUP when you quit, et cetera. This is the minutae on how the OS accomplishes that. It needs to know what processes belong to you to do that, and "you" means your login - i.e. your controlling terminal.
This assumption goes pretty deep. Things like sudo and ssh directly talk to your controlling terminal to get passwords securely, in the expectation that a terminal is a direct realtime line to the user - and if there isn't any controlling terminal, it shouldn't even try to ask for a password.
This control scheme goes all the way back to serial line modems. Some features come directly from that - like process cleanup on exit. When a serial line modem disconnects, it tells the operating system, causing the operating system to send SIGHUP - hangup - to all the processes spawned from it!