When process groups are usually created

process-groupsprocess-management

I have a program that spawns many instances of other programs. I want to have a clean way to kill them after timeout, even if they spawn subprocesses, sometimes accidentally daemonize, etc.

Right now I use process group approach: each instance is run in its own process group, and I signal the entire group when I want to kill it. And it seems to work fine so far.

However, it's very easy to create a new process group and thus escape from my control. Those programs are not inherently malicious (so they won't try to do this on purpose), but can be very sloppily written. They could be Python scripts, ugly shell scripts, things like that.

So my question is, when exactly process groups are usually created? According to my observations, interactive shells create them, but non-interactive don't. For instance, are they any kind of advanced shell constructs that tend to create new process groups even in non-interactive scripts?

Best Answer

Well, "sometimes accidentally daemonize" would be a problem—part of daemonizing is to disassociate from the process group. See, e.g., Daemonize's page or a Unix Programming FAQ.

Other than that, the one I've come across[*] is script, which sometimes you have to use to capture a command's output (e.g., because it behaves differently when attached to a terminal vs. a pipe). script calls setsid, which also starts a process group.

It's also possible to turn on job control inside a script, which'd probably also do it. Not sure how common that is, though.

[*] I personally have a script I use frequently that runs mpv inside a script, and parses the output.

Related Solutions

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.

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

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.

Best Answer

Related Solutions

Shell – What should interactive shells do in orphaned process groups

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

Related Question