outcome of `Command::status` changes depending on whether `posix_spawn` or `execvp` is used internally

[japaric]

I tried this:

$ rm -f /tmp/empty
$ touch /tmp/empty
$ chmod 0555 /tmp/empty
$ cargo new --bin hello
$ cd hello
$ $EDITOR src/main.rs
$ cat src/main.rs

use std::process::Command;
fn main() {
    _ = dbg!(Command::new("/tmp/empty").status());
}

• On Ubuntu 20.04

$ ldd --version | head -n1
ldd (Ubuntu GLIBC 2.31-0ubuntu9.17) 2.31

$ cargo run
[src/main.rs:3:9] Command::new("/tmp/empty").status() = Err(
    Os {
        code: 8,
        kind: Uncategorized,
        message: "Exec format error",
    },
)

• On Centos 7

$ ldd --version | head -n1
ldd (GNU libc) 2.17

$ cargo run
[src/main.rs:3:9] Command::new("/tmp/empty").status() = Ok(
    ExitStatus(
        unix_wait_status(
            0,
        ),
    ),
)

I expected to see this happen: the same behavior regardless of the glibc version.

Instead, this happened: whether you get an error or success depends on the system libc version

Meta

rustc --version --verbose:

binary: rustc
commit-hash: 12c36e2539c54397c51d6ea4401defd8768a4f5b
commit-date: 2026-08-10
host: x86_64-unknown-linux-gnu
release: 1.99.0-nightly
LLVM version: 23.1.0

Investigation

AFAICT, the difference is due to Command::spawn using libc::posix_spawn on GLIBC 2.24 and newer; and execvp older GLIBC versions 1. the posix_spawn logic produces the Err outcome; the execvp logic produces the Ok outcome

patching libstd to never take the posix_spawn lets me reproduce the Ok outcome on Ubuntu 22.04 (glibc 2.35)

[bjorn3]

Why is executing an empty file even possible in the first place with execve? The posix_spawn behavior seems correct to me.

[joboet]

We're not using execve but rather execvp, which will invoke the shell (/bin/sh on Linux and the BSDs) with the program as argument if the internal execve call with the program fails with ENOEXEC (UNIX specifies this). This also causes a rather nasty soundness bug in Command::exec since we need to modify the global environ pointer, see #156951.

#157144 will fix all this, but might subtly change the behaviour on platforms like macOS, where the ENOEXEC behaviour occurs even with posix_spawnp, even though the UNIX specification forbids this:

However, if at least one of the exec family of functions would fail with [ENOEXEC] because the process image contents are not executable, this shall cause posix_spawnp() to fail rather than attempting a fallback to invoking the process as a shell script passed to sh.

Looking through all the UNIX platforms to investigate whether #157144 will change behaviour has been on my todo-list for a long time, you're very welcome to help out!