> How?! After a process calls setsid(2), it becomes a leader of a new process group so it stops receiving signals from its former process group!

By limiting its usage to the period between fork and exec, so that the process calling setsid knows that the parent process is propagating signals to it.

So, my phrasing was inaccurate to the point of being entirely incorrect. I should have said that any process that calls `setsid` is responsible for ensuring that signals are being propagated. (And saved! Definitely didn't make a mistake on the internet and then play it like I was right all along.)

> any process that calls `setsid` is responsible for ensuring that signals are being propagated.

Well, again, the process that calls setsid(2) ceases to receive the signals from its previous process group, so there is nothing for it to propagate. The only way this propagation can work is with cooperation from the parent process of the setsid-calling process: it will need to manually pass the group-wide signals to its setsid-calling child — which it can't reliably do for two obvious reasons.

> By limiting its usage to the period between fork and exec, so that the process calling setsid knows that the parent process is propagating signals to it.

Wait. Are you implying a scheme where the process A, that wants to do setsid(2), forks itself, and it's this child process B that does setsid(2) and all future actual work, while process A merely lives in a "while(1) { sig = sigwait(); signal(pidB, sig); }" loop forever? This almost works but doesn't survive SIGSTOP/SIGCONT/etc. and, of course, you can't propagate SIGKILL. And SIGKILL-propagation is arguably one of the main attraction of the process groups — you send SIGKILL to the process group (or a container, for that matter), and all of it dies with no further work on your part.