Change process spawning to inherit the parent's signal mask by default

[sunshowers]

Previously, the signal mask was always reset when a child process is
started. This breaks tools like nohup which expect SIGHUP to be
blocked for all transitive processes.

With this change, the default behavior changes to inherit the signal mask.

This also changes the signal disposition for SIGPIPE to only be changed if the #[unix_sigpipe] attribute isn't set.

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[sunshowers]

r? @thomcc

[sunshowers]

(I don't know of a way to represent the stack cleanly in GitHub, unlike in Gerrit, Phabricator's Differential or other tools.)

[thomcc]

Ideally it would be cleanly separated from the other (I know this is a bit of a pain). That would make it easier to FCP and land on its own.

[sunshowers]

It's not really possible to cleanly separate. Best one could do is to change the ordering so that #100737 depends on this rather than the other way round.

To avoid duplicated work I would like to skip doing that for now. I'd be happy to do that after the FCP regarding this is approved.

[thomcc]

Sure. I'll assign to someone who can start an FCP for this (I really need to get to rust-lang/rfcbot-rs#306... maybe on Monday...). For their context, this is based on this comment from @zackw: #100737 (comment)

r? @joshtriplett

[bors]

☔ The latest upstream changes (presumably #100786) made this pull request unmergeable. Please resolve the merge conflicts.

[sunshowers]

Is there anything blocking this? @joshtriplett @thomcc

Once this is accepted I'd be happy to change the ordering of the PRs and resolve merge conflicts, etc.

[joshtriplett]

I think the handling for SIGPIPE needs some updates, for two reasons:

• This should take Support #[unix_sigpipe = "inherit|sig_dfl"] on fn main() to prevent ignoring SIGPIPE #97802 into account, rather than unconditionally unblocking.
• If the user uses block_signal on SIGPIPE, we should respect that and not override it.

[joshtriplett]

@rustbot author

[rustbot]

Error: The "Author" shortcut only works on pull requests.

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[Enselic]

This should take Support #[unix_sigpipe = "inherit|sig_dfl"] on fn main() to prevent ignoring SIGPIPE #97802 into account, rather than unconditionally unblocking.

Would you mind elaborating a bit on that please? In my mind that attribute only affects what the runtime does to SIGPIPE before fn main() is invoked. I don't think it should affect the spawning of child processes? (Except indirectly)

[joshtriplett]

"except indirectly" is exactly my concern here. Right now, and with this patch, Rust resets SIGPIPE to default in the child process. I think if the user sets the sigpipe disposition with that attribute, we should allow that to be inherited unless overridden.

[Enselic]

Hmm, in that case we should probably make #[unix_sigpipe = "..."] a module attribute rather than an attribute on fn main(), because otherwise the behaviour of inheritance of parent signal masks can't be configured for library code. But if we make it an attribute that can be used with libraries, how do we handle when two different libraries that are in use choose different values on the attribute?

To me, these problems suggest that the #[unix_sigpipe = "..." "belongs" to fn main(), since without an fn main(), no code is generated that can configure SIGPIPE before fn main() is invoked.

I think it is useful to think about what we would do if the Rust runtime would never have started to touch SIGPIPE in 2014. If that would have been the case, how would we have written the code in this PR? And I think the answer to that is "we do not treat SIGPIPE any different than any other signal", so that seems to me to be what we should do also today here.

But I am of course open to be convinced otherwise.

[joshtriplett]

@Enselic I agree, and I wish we could do that, but I think that would break backwards compatibility at the moment.

I'm proposing that if something sets the attribute at all, regardless of the value they set it to, we treat that as an opt in to not touching the signal here.

If a library wants to treat sigpipe differently, it can call block_signal or similar, which this code should respect.

[sunshowers]

I've been away for a bit. Going to tackle this in the next few days.

[sunshowers]

@joshtriplett Some questions:

1. How should reset_sigpipe:

   rust/library/std/src/sys/unix/mod.rs

   Lines 156 to 181 in 8c6ce6b

   	unsafe fn reset_sigpipe(#[allow(unused_variables)] sigpipe: u8) {
   	#[cfg(not(any(target_os = "emscripten", target_os = "fuchsia", target_os = "horizon")))]
   	{
   	// We don't want to add this as a public type to libstd, nor do we
   	// want to `include!` a file from the compiler (which would break
   	// Miri and xargo for example), so we choose to duplicate these
   	// constants from `compiler/rustc_session/src/config/sigpipe.rs`.
   	// See the other file for docs. NOTE: Make sure to keep them in
   	// sync!
   	mod sigpipe {
   	pub const INHERIT: u8 = 1;
   	pub const SIG_IGN: u8 = 2;
   	pub const SIG_DFL: u8 = 3;
   	}
   	let handler = match sigpipe {
   	sigpipe::INHERIT => None,
   	sigpipe::SIG_IGN => Some(libc::SIG_IGN),
   	sigpipe::SIG_DFL => Some(libc::SIG_DFL),
   	_ => unreachable!(),
   	};
   	if let Some(handler) = handler {
   	rtassert!(signal(libc::SIGPIPE, handler) != libc::SIG_ERR);
   	}
   	}
   	}

   communicate with process spawning code? My first thought was to use a static AtomicBool, but I'm wondering if it'll run into issues given how early in the process this happens. Do you have other/better suggestions? Note that simply fetching the current signal disposition will not work, because we need to differentiate between #[unix_sigpipe = "sig_ign"] and no attribute specified.

2. Note that this PR touches setsigmask (AIUI a mask of signals currently blocked from delivery, though can be delivered in the future), not setsigdefault (signals that are reset to default signal handling, but which can still potentially be temporarily blocked by my understanding). If block_signal is called, that doesn't directly affect setsigdefault, only setsigmask.

   1. How should the behavior of setsigdefault change under block_signal?
   2. If SIGPIPE is currently blocked in this process, and unblock_signal is called, what should happen to the behavior of setsigdefault?

3. What's the best way to test this behavior? It seems like there are a number of different combinations involved here.

[bors]

☀️ Test successful - checks-actions
Approved by: sunshowers
Pushing 57e2c06 to master...

[rust-timer]

Finished benchmarking commit (57e2c06): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

This benchmark run did not return any relevant results for this metric.

[passcod]

Just some feedback that this broke cargo-watch as we set sigmask on the parent process and relied on the sigmask reset for children to run them as the user expected.

[sunshowers]

You can fix it locally by temporarily setting the right sigmask in the spawning thread. See https://github.com/nextest-rs/nextest/blob/2505a731eadd7b7bc7355a53e753a05d822a358d/nextest-runner/src/double_spawn.rs#L167 for an example.

It's certainly a breaking change, but the old behavior was incorrect.

[passcod]

It just seems weird because the previous thing was deliberately done: #25784