Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a tokio::process::Child in a new process group #4312

Closed
kpcyrd opened this issue Dec 10, 2021 · 7 comments · Fixed by #5114
Closed

Create a tokio::process::Child in a new process group #4312

kpcyrd opened this issue Dec 10, 2021 · 7 comments · Fixed by #5114
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-process Module: tokio/process

Comments

@kpcyrd
Copy link

kpcyrd commented Dec 10, 2021

Is your feature request related to a problem? Please describe.

I want to create a child process and later be able to kill this child with all of it's sub- and sub-sub- children on unix-style operating systems.

Describe the solution you'd like

Something along the lines of:

.set_process_group(0)

Describe alternatives you've considered

I'm currently using this code to implement it:

    unsafe {
        cmd.pre_exec(|| {
            // create a new process group
            let pid = nix::unistd::getpid();
            if let Err(err) = nix::unistd::setpgid(pid, Pid::from_raw(0)) {
                warn!("Failed to create new process group: {:#?}", err);
            }
            Ok(())
        });
    }

setpgid needs to be called before exec is called after fork.

Additional context

https://www.gnu.org/software/libc/manual/html_node/Process-Group-Functions.html

@kpcyrd kpcyrd added A-tokio Area: The main tokio crate C-feature-request Category: A feature request. labels Dec 10, 2021
@Darksonn Darksonn added the M-process Module: tokio/process label Dec 10, 2021
@Darksonn
Copy link
Contributor

Thoughts @ipetkov ?

@ipetkov
Copy link
Member

ipetkov commented Dec 10, 2021

Unfortunately, I think this is the only way to accomplish this. We pretty much wrap the stdlib types, and there aren't any OS extensions that I could find which do the setpgid calls for us

@kpcyrd
Copy link
Author

kpcyrd commented Dec 10, 2021

Would it help if I propose this extension in the stdlib?

@ipetkov
Copy link
Member

ipetkov commented Dec 10, 2021

It's worth a shot! We don't need to wait on the stdlib to potentially add such a wrapper, but having the feature parity would be nice

@danyspin97
Copy link

The stdlib has process_group in std::os::unix::process::CommandExt but it's unstable for now.

@ipetkov
Copy link
Member

ipetkov commented Jul 27, 2022

Looks like process_group was stabilized and will land on 1.64

@ipetkov
Copy link
Member

ipetkov commented Jul 27, 2022

I think next steps for this are:

  • wait for 1.64 to be released
  • add a process_group API behind a tokio_unstable flag
  • stabilize the API once our MSRV policy allows for requiring a compiler that is >= 1.64

HarveyHunt added a commit to HarveyHunt/tokio that referenced this issue Oct 21, 2022
Rust 1.64 stabilised the `process_group` method of the
`std::os::unix::process::CommandExt` trait. This allows the
caller to set the process group that a command is spawned in.

Expose that functionality from Tokio's `Command` structure.

This fixes tokio-rs#4312.
HarveyHunt added a commit to HarveyHunt/tokio that referenced this issue Oct 21, 2022
Rust 1.64 stabilised the `process_group` method of the
`std::os::unix::process::CommandExt` trait. This allows the
caller to set the process group that a command is spawned in.

Expose that functionality from Tokio's `Command` structure.

This fixes tokio-rs#4312.
HarveyHunt added a commit to HarveyHunt/tokio that referenced this issue Oct 21, 2022
Rust 1.64 stabilised the `process_group` method of the
`std::os::unix::process::CommandExt` trait. This allows the
caller to set the process group that a command is spawned in.

Expose that functionality from Tokio's `Command` structure.

This fixes tokio-rs#4312.
HarveyHunt added a commit to HarveyHunt/tokio that referenced this issue Oct 21, 2022
Rust 1.64 stabilised the `process_group` method of the
`std::os::unix::process::CommandExt` trait. This allows the
caller to set the process group that a command is spawned in.

Expose that functionality from Tokio's `Command` structure.

This fixes tokio-rs#4312.
HarveyHunt added a commit to HarveyHunt/tokio that referenced this issue Oct 21, 2022
Rust 1.64 stabilised the `process_group` method of the
`std::os::unix::process::CommandExt` trait. This allows the
caller to set the process group that a command is spawned in.

Expose that functionality from Tokio's `Command` structure.

This fixes tokio-rs#4312.
HarveyHunt added a commit to HarveyHunt/tokio that referenced this issue Oct 26, 2022
Rust 1.64 stabilised the `process_group` method of the
`std::os::unix::process::CommandExt` trait. This allows the
caller to set the process group that a command is spawned in.

Expose that functionality from Tokio's `Command` structure,
behind the unstable feature.

This fixes tokio-rs#4312.
HarveyHunt added a commit to HarveyHunt/tokio that referenced this issue Oct 26, 2022
Rust 1.64 stabilised the `process_group` method of the
`std::os::unix::process::CommandExt` trait. This allows the
caller to set the process group that a command is spawned in.

Expose that functionality from Tokio's `Command` structure,
behind the unstable feature.

This fixes tokio-rs#4312.
HarveyHunt added a commit to HarveyHunt/tokio that referenced this issue Oct 27, 2022
Rust 1.64 stabilised the `process_group` method of the
`std::os::unix::process::CommandExt` trait. This allows the
caller to set the process group that a command is spawned in.

Expose that functionality from Tokio's `Command` structure,
behind the unstable feature.

This fixes tokio-rs#4312.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-tokio Area: The main tokio crate C-feature-request Category: A feature request. M-process Module: tokio/process
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants