What does glibc 2.34 close_range() actually do when the running kernel does not support the close_range system call? does it return -1 with errno=ENOSYS [desirable] or does it implement its own potentially poor unsafe version of close_range?

I'd checked that before opening the PR. The glibc manual (which is not the same as the kernel man pages project you linked to) explicitly states that close_range() doesn't provide any fallbacks. This is in contrast to closefrom(), which not only provides a procfs-based fallback, but aborts if that fallback fails, and hence would be unsuitable not only for subprocess, but for os.closerange() as well.

Glibc, however, does have a surprise: it contains a close_range() fallback for GNU Hurd, which doesn't look async-signal-safe at all, and also a generic fallback iterating over all fds up to the fd limit (for mostly theoretical non-Linux and non-Hurd builds).

Other Linux C libraries that I've checked (musl, bionic, uclibc-ng) don't currently provide close_range() wrapper, but I think they will follow glibc if/when they provide it.

Note that close_range() is also present on FreeBSD, where it's a system call too.

Overall, I think it makes sense to enable the new code for known-good platforms only. I've added extra ifdefs.

An alternative to platform whitelisting is to use a direct syscall (and assume that whenever we have SYS_close_range, the interface is what we expect).