Add a process_group method to UNIX CommandExt

[krallin]

• Tracking issue: Tracking Issue for process_set_process_group #93857
• RFC: RFC: Add a process_group method to UNIX CommandExt rfcs#3228

Add a process_group method to std::os::unix::process::CommandExt that
allows setting the process group id (i.e. calling setpgid) in the child, thus
enabling users to set process groups while leveraging the posix_spawn fast
path.

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Mark-Simulacrum (or someone else) soon.

Please see the contribution instructions for more information.

[joshtriplett]

Looks good to me!

@bors r+

[bors]

📌 Commit abb4a0e has been approved by joshtriplett

[matthiaskrgr]

@bors r- failed in a rollup
#93919 (comment)
on auto (dist-various-2, ubuntu-20.04-xl)

error: associated function is never used: `get_pgroup`
   --> library/std/src/sys/unix/process/process_common.rs:275:12
    |
275 |     pub fn get_pgroup(&self) -> Option<pid_t> {
    |            ^^^^^^^^^^
    |
    = note: `-D dead-code` implied by `-D warnings`

[RUSTC-TIMING] std test:false 3.999
error: could not compile `std` due to previous error

[krallin]

Oh, I see the getter functions in here all have a allow(dead_code) annotations, so I should probably be doing the same here!

…

On Fri, 11 Feb 2022 at 20:47, Matthias Krüger ***@***.***> wrote: @bors <https://github.com/bors> r- failed in a rollup #93919 (comment) <#93919 (comment)> on auto (dist-various-2, ubuntu-20.04-xl) <https://github.com/rust-lang-ci/rust/runs/5161867981?check_suite_focus=true#logs> error: associated function is never used: `get_pgroup` --> library/std/src/sys/unix/process/process_common.rs:275:12 | 275 | pub fn get_pgroup(&self) -> Option<pid_t> { | ^^^^^^^^^^ | = note: `-D dead-code` implied by `-D warnings` [RUSTC-TIMING] std test:false 3.999 error: could not compile `std` due to previous error — Reply to this email directly, view it on GitHub <#93858 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANIHVVLZXNSX2E2TMF2DS3U2VYX7ANCNFSM5OAUZV7Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[krallin]

(updated)

[krallin]

Hmm, is that the right fix though?

I see the failure is on fuchsia. It looks like it only supports a subset of the operations on the UNIX CommandExt (e.g. groups doesn't work either), as per library/std/src/sys/unix/process/process_fuchsia.rs.

Is this something I should tackle here (e.g. return an error when this is set on fuschia?), or is this OK for this to behave like e.g. groups, that is, to do nothing silently?

[krallin]

Hey @joshtriplett , sorry to ping, but since you were very helpful so far: any guidance on how I should deal with Fuschia?

(I should mention that I definitely don't have a Fuschia machine so testing changes in that build might be tricky for me!)

[dtolnay]

This looks good to me.

It looks like fuchsia only supports a subset of the operations on the UNIX CommandExt (e.g. groups doesn't work either), as per library/std/src/sys/unix/process/process_fuchsia.rs. Is this something I should tackle here (e.g. return an error when this is set on fuschia?), or is this OK for this to behave like e.g. groups, that is, to do nothing silently?

Please add an item to the tracking issue to confirm how the Fuchsia folks want to implement this prior to stabilization.

FYI @tmandry.

[dtolnay]

@bors r+ rollup=iffy

[bors]

📌 Commit 6d7d6e1 has been approved by dtolnay

[bors]

⌛ Testing commit 6d7d6e1 with merge 1474108e2fc91238a61b927275659a9a013ee202...

[bors]

💥 Test timed out

[krallin]

Looking at the logs I think the timeouts might be legit, since I can see this in the armhf-gnu, ubuntu-20.04-xl build:

test sys::unix::process::process_common::tests::test_process_group_no_posix_spawn has been running for over 60 seconds
test sys::unix::process::process_common::tests::test_process_group_posix_spawn has been running for over 60 seconds

Any suggestions for how I might repro this? My initial guess would be that the platform this is running on doesn't set the SIGINIT handler to kill by default, so I'd be inclined to update the test to send SIGKILL instead of SIGINT, but curious if there is a way I could check that works?

Thanks!

[nikic]

@bors r- accidentally got back in the queue

[niklasf]

One of the surrounding test cases is preceded by

rust/library/std/src/sys/unix/process/process_common/tests.rs

Lines 18 to 32 in ed2a69c

	#[cfg_attr(
	any(
	// See #14232 for more information, but it appears that signal delivery to a
	// newly spawned process may just be raced in the macOS, so to prevent this
	// test from being flaky we ignore it on macOS.
	target_os = "macos",
	// When run under our current QEMU emulation test suite this test fails,
	// although the reason isn't very clear as to why. For now this test is
	// ignored there.
	target_arch = "arm",
	target_arch = "aarch64",
	target_arch = "riscv64",
	),
	ignore
	)]

which was originally added together with that CI target (1747ce2).

So unless we can figure out the mysterious issue with signals under QEMU in CI, it's probably best to move along and apply the same attributes to the new tests.

[krallin]

Thanks @niklasf, I updated this accordingly :)

[dtolnay]

@bors r+ rollup=iffy

[bors]

📌 Commit b628497 has been approved by dtolnay