The history of sending signals to Unix process groups

If anyone can suggest an update to <a href="https:&#x2F;&#x2F;github.com&#x2F;oconnor663&#x2F;duct.py&#x2F;blob&#x2F;master&#x2F;gotchas.md#killing-grandchild-processes" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;oconnor663&#x2F;duct.py&#x2F;blob&#x2F;master&#x2F;gotchas.md...</a>, please let me know. As far as I&#x27;m aware, there&#x27;s still no reliable way to kill a tree of processes on Unix that&#x27;s suitable for library code.

All I ever wanted was to type ^C (or perhaps ^\) in my terminal and kill in one fell swoop all the shite that my previous shell-typed command spawned directly or indirectly.<p>This, IIRC used to be the standard behavior back in the days, but in recent years, for some reasons, things have not been so simple.<p>Looking at the man page of ps(1) sort of starts to elucidate the effing mess that the name &quot;group&quot; summons the in unix process world.<p>Are we talking about the real group id (RGID), the effective group id (EGID), the controlling progress group id (TPGID), the control group (CGROUP) the textual group id (EGROUP), the filesystem group id (FGID), the textual filesystem group id (FGID), the process id of the process group leader (PGID), the saved group id (SGID), the session id (SID), the supplementary group id (SUPGID), the thread group id (TGID) ?<p>I&#x27;m pretty sure I&#x27;m missing some.<p>What an effing mess.

If one is familiar with POSIX and why it is how it is, one knows that the reason that POSIX has both sessions and process groups is that &quot;sessions&quot; pretty much descend from AT&amp;T System 3 process groups and &quot;process groups&quot; descend from BSD process groups; so one would indeed have expected that there were two separate ideas of &quot;process group&quot;.<p>Things that this history does not cover include System 5 Release 2 &quot;shell layers&quot;. Shell layers multiplexed virtual terminals onto a single physical terminal, preceding its obvious successors screen by somewhere around three years, and tmux by about quarter of a century. The popularity of tmux and screen nowadays shows that the BSD job control mechanism did not entirely kill off the vision of shell layers, as I recall people thinking it had at the time.

Process groups and job control is a huge fucking mess on Unix. Process groups, job control, and signals are probably the biggest mistakes of Unix&#x27;s design. Arguably fork(2) as well, but that&#x27;ll probably raise some eyebrows. The blame for Berkley sockets and ioctls can&#x27;t entirely be laid at Unix&#x27;s feet, but they&#x27;re also quite the mess.

It’s a mess that originates from the dated concept of terminals and that users are necessarily bound with interactive sessions from them. Without the notion of terminals and special control sequences, process hierarchy control can be much simpler and more orthogonal. A “signal” would be sent to the leaf processes in the hierarchy first, then they terminate, notifying their parent and so on.

Question: can we control a Linux process (with all its threads, signal handlers etc.) in a completely deterministic way, e.g. by using ptrace() on it?

killpg is my favorite syscall