Process Groups – Purpose of Abstractions, Session, Session Leader and Process Groups

job-controlprocess-groupssession

I understand from Informit article that sessions and process groups are used to terminate descendant processes on exit and send signals to related processes with job control.

I believe this information can be extracted at any point using the PPID of every process. Do these concepts exist in place just to have a data structure that enables getting descendants of a process quickly?

Do session and process groups get employed in things other than job control and termination of descendants? do they store any context information?

Any good references will be helpful.

Best Answer

Process groups exist primarily to determine which processes started from a terminal can access that terminal. Only processes in the foreground process group may read or write to their controlling terminal; background processes are stopped by a SIGTTIN or SIGTTOU signal.

You can send a signal atomically to all the processes in a process group, by passing a negative PID argument to kill. This also happens when a signal is generated by the terminal driver in response to a special character (e.g. SIGINT for Ctrl+C).

Sessions track which process groups are attached to a terminal. Only processes running in the same session as the controlling process are foreground or background processes.

It is not possible to determine process groups or sessions from the PPID. You would have no way to know whether the parent of a process is in the same process group or a different one, and likewise for sessions.

Related Solutions

Process Groups vs Job Control – Key Differences

A process group is a unix kernel concept. It doesn't come up very often. You can send a signal to all the processes in a group, by calling the kill system call or utility with a negative argument.

When a process is created (with fork), it remains in the same process group as its parent. A process can move into another group by calling setpgid or setpgrp. This is normally performed by the shell when it starts an external process, before it executes execve to load the external program.

The main use for process groups is that when you press Ctrl+C, Ctrl+Z or Ctrl+\ to kill or suspend programs in a terminal, the terminal sends a signal to a whole process group, the foreground process group. The details are fairly complex and mostly of interest to shell or kernel implementers; the General Terminal Interface chapter of the POSIX standard is a good presentation (you do need some unix programming background).

Jobs are an internal concept to the shell. In the simple cases, each job in a shell corresponds to a process group in the kernel.

Shell – What should interactive shells do in orphaned process groups

I agree with your analysis and I agree it sounds like you have to detect whether your process group is orphaned or not.

tcsetattr is also meant to return EIO if the process group is orphaned (and we're not blocking/ignoring SIGTTOU. That might be a less intrusive way than a read on the terminal.

Note that you can reproduce it with:

(bash<&1 &)

You need the redirection otherwise stdin is redirected to /dev/null when running a command in the background.

(bash<&1 & sleep 2)

Gives even weirder behaviour, as because you end up with two shells reading from the terminal. They are ignoring SIGTTIN and the new one is not detecting, once it's started that it is no longer in the foreground process group.

ksh93's solution is not so bad: only go up to 20 times (instead of infinite) through that loop before giving up.

Best Answer

Related Solutions

Process Groups vs Job Control – Key Differences

Shell – What should interactive shells do in orphaned process groups

Related Question