Skip to content

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

Open

Description

@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".

Activity

  1. A5rocks commented on Jul 14, 2025

    @A5rocks
    Contributor

    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 :-)

  2. neongreen commented on Jul 15, 2025

    @neongreen
    Author

    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

  3. A5rocks commented on Sep 26, 2025

    @A5rocks
    Contributor

    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.

  4. nightcityblade commented on Apr 14, 2026

    @nightcityblade

    Hi, I'd like to work on this. I'll submit a PR shortly.

  5. Madhur-7568 commented on Jul 14, 2026

    @Madhur-7568
    Contributor

    Hi, I'd like to work on this , can i make a pr.

  6. A5rocks commented on Jul 15, 2026

    @A5rocks
    Contributor

    Of course you can make a PR. However, it's a bit of a challenge to write docs that fix this, IIRC.

  7. Madhur-7568 commented on Jul 25, 2026

    @Madhur-7568
    Contributor

    I'm thinking of expanding the existing Ctrl+C note to mention this behaviour and explain when process_group or start_new_session might be useful. Does that sound like the right direction?

  8. Madhur-7568 commented on Jul 31, 2026

    @Madhur-7568
    Contributor

    Hi! Just following up on my previous message. Please let me know when you have a chance.

  9. A5rocks commented on Jul 31, 2026

    @A5rocks
    Contributor

    I kind of forgot all the context for this issue and will only try to remember if there's actually a patch to the docs being proposed :P

    All I remember thinking is that I don't really know the optimal resolution for this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions