Code change:
pub fn new_raw(fam: c_int, ty: c_int) -> io::Result<Socket> { unsafe { <del> // On linux we first attempt to pass the SOCK_CLOEXEC flag to // atomically create the socket and set it as CLOEXEC. Support for // this option, however, was added in 2.6.27, and we still support // 2.6.18 as a kernel, so if the returned error is EINVAL we // fallthrough to the fallback. #[cfg(target_os = "linux")] { match cvt(libc::socket(fam, ty | libc::SOCK_CLOEXEC, 0)) { Ok(fd) => return Ok(Socket(FileDesc::new(fd))), Err(ref e) if e.raw_os_error() == Some(libc::EINVAL) => {} Err(e) => return Err(e), } } let fd = cvt(libc::socket(fam, ty, 0))?; let fd = FileDesc::new(fd); fd.set_cloexec()?; let socket = Socket(fd); </del> <ins> cfg_if::cfg_if! { if #[cfg(target_os = "linux")] { // On Linux we pass the SOCK_CLOEXEC flag to atomically create // the socket and set it as CLOEXEC, added in 2.6.27. let fd = cvt(libc::socket(fam, ty | libc::SOCK_CLOEXEC, 0))?; Ok(Socket(FileDesc::new(fd))) } else { let fd = cvt(libc::socket(fam, ty, 0))?; let fd = FileDesc::new(fd); fd.set_cloexec()?; let socket = Socket(fd); </ins> <del> // macOS and iOS use `SO_NOSIGPIPE` as a `setsockopt` // flag to disable `SIGPIPE` emission on socket. #[cfg(target_vendor = "apple")] setsockopt(&socket, libc::SOL_SOCKET, libc::SO_NOSIGPIPE, 1)?; </del> <ins> // macOS and iOS use `SO_NOSIGPIPE` as a `setsockopt` // flag to disable `SIGPIPE` emission on socket. #[cfg(target_vendor = "apple")] setsockopt(&socket, libc::SOL_SOCKET, libc::SO_NOSIGPIPE, 1)?; </ins> <del> Ok(socket) </del> <ins> Ok(socket) } } </ins> } }

Related discussion:
text: Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: uses the flag with  (mentioned above, in 2.6.23) uses with  ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") uses  to atomically set the flag on the pipe fds ( in 2.6.27) uses with  ( in 2.6.27) uses  to permit use of ( in 2.6.28) ~ ( in 4.5, not fixed by this proposal)~ As you can see, the workarounds fixed by this proposal all have a similar flavor. Originally posted by in
Kernel updated in .
As noted, needs a much newer kernel 4.5, so we'll still need that fallback. But all the stuff should be ok to assume available now.
The new minimal version is 2.6.27 from what I can see, so "Socket::accept uses accept4(2) to permit use of SOCK_CLOEXEC" still needs a fallback, right?
The builder is using 2.6.32 headers, so I would call that our new minimum.
Ah right; I am actually not sure where I got the 27 from...
The title of suggested 2.6.27, but we went a little higher to match the actual distros in use.
I know this is ancient history, but do you recall the problem with ? You introduced that comment about "some kernel" in , and you were the last to update it in . If the problem kernels were before 2.6.32, then I'd like to clean that up now.
Just digging in kernel history, I did find one hiccup in , but that bug was introduced and resolved during the 3.7 development cycle, not in a release.
IIRC we just mirrored what musl did at the time, which looks like it : Looks like the original mailing list thread is gone and there's no comments in the musl source, and I don't recall what happened here. I suspect it would be safe to remove those workarounds and just assume works one the first try until someone says differently.