run_process: Document pitfalls re/ Ctrl+C and not creating a new process group

[neongreen]

I know the docs already mention process groups;

However, I had no idea about the existence of background and foreground groups, and didn't know that a grandchild process could take control of Ctrl+C handling if it becomes a foreground process and pushes my process into background (?). So I spent quite a lot of time trying to figure out why Ctrl+C wasn't reaching my process at all.

#3273 is relevant, but even for non-shell invocations of run_process it's still possible to lose control over Ctrl+C unless you use smth like "start_new_session".

[A5rocks]

You can use pstree to debug what is a parent to what!

Would it have been valuable to you to have any of the following?:

• default to process_group=0 for non-shell processes too. (I don't know how to do something nicely on Windows)
• document how to debug a weird process topology (? is that the word) with a short example

Does start_new_session help? My impression was that it's mostly for setting up a controlling terminal but I also don't really know my way around Unix :-)

[neongreen]

start_new_session helps, yeah, but now that i've read the docs I wonder if maybe I should've used process_group=0 instead.

I used procs to show the tree, but I think my children are my children regardless of what process group they're in? Not sure

default to process_group=0 for non-shell processes too.

This would've helped for my usecase but I also don't know my way around Unix (apparently 😭) so I can't say if it's a good idea in general or not

document how to debug a weird process topology (? is that the word) with a short example

The problem is that I had no idea process groups were even relevant for Ctrl+C handling, so having perfect awareness of the process topology would not have helped me, I suppose

[A5rocks]

OK, so I actually ran into https://github.com/oconnor663/duct.py/blob/master/gotchas.md and it suggests that cgroups (shock! horror!) are a good default. Ie just make a cgroup for every spawned subprocess and then you can atomically send a signal to that.

(And that "job groups" exist on Windows. So it would work... except on macos/bsd stuff...)

I would be happy with that default!

---

Though now that I'm rereading this issue I think you were running into something else... oh well.