Change:
!INVALID.load(Ordering::SeqCst) { <del> if let Some(pipe) = pipe2.get() { // Note that despite calling a glibc function here we may still // get ENOSYS. Glibc has `pipe2` since 2.9 and doesn't try to // emulate on older kernels, so if you happen to be running on // an older kernel you may see `pipe2` as a symbol but still not // see the syscall. match cvt(unsafe { pipe(fds.as_mut_ptr(), libc::O_CLOEXEC) }) { Ok(_) => { return Ok((AnonPipe(FileDesc::new(fds[0])), AnonPipe(FileDesc::new(fds[1])))); } Err(ref e) if e.raw_os_error() == Some(libc::ENOSYS) => { INVALID.store(true, Ordering::SeqCst); } Err(e) => return Err(e), </del> <ins> // Note that despite calling a glibc function here we may still // get ENOSYS. Glibc has `pipe2` since 2.9 and doesn't try to // emulate on older kernels, so if you happen to be running on // an older kernel you may see `pipe2` as a symbol but still not // see the syscall. match cvt(unsafe { pipe2(fds.as_mut_ptr(), libc::O_CLOEXEC) }) { Ok(_) => { return Ok((AnonPipe(FileDesc::new(fds[0])), AnonPipe(FileDesc::new(fds[1])))); } Err(ref e) if e.raw_os_error() == Some(libc::ENOSYS) => { INVALID.store(true, Ordering::SeqCst); </ins> } <ins> Err(e) => return Err(e), </ins> } } cvt(unsafe { libc::pipe(fds.as_mut_ptr()) })?;

Discussion:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.