How to check if `closefrom` can be used for closing file descriptors at runtime?

Question

I'm looking to write some C code that will close all the currently open file descriptors, suitable to be used as part of a fork/exec to make a new process.

I know from the answer here that there are various platform-specific functions to do this efficiently, such as closefrom on Linux, but they're not available in all C libs (like musl) or kernels.

Most solutions I've seen check for the availability of these functions using compile time macros, but I'd like to try to do so at runtime. The idea is to have some code suitable for compiling statically and using on various platforms. The requirements are thus:

1. If the underlying kernel supports it, make use of closefrom functionality.
2. Otherwise, fall back to traditional means like looping through all possible file descriptors or reading from /proc.

One idea I had for Linux systems was just to call the syscall number, but I'd love to hear from C experts if this is a good idea:

#define CLOSE_RANGE_SYSCALL_NUMBER 436

void my_closefrom(int lowfd, int to) {
    long ret = syscall(CLOSE_RANGE_SYSCALL_NUMBER, lowfd, to, 0);

    if (ret != -1) {
        // Success!
    } else {
        // Otherwise, fall back to another approach
        // ...
    }
}

Answer 1

From a comments on the question:

[I'm looking for] the ability to statically link once and then run it on systems different from the one I compiled it on.

I should be able to run this on a Linux system with kernel >= 5.9 and get the performance boost, or run it on an earlier kernel and not. AFAIK the only "ABI" compatibility that would be relevant would be whether the kernel provides the desired syscall

Well no. There is also the question of what the syscall number is. And for some syscalls, what the argument format is expected to be. And since you intend to link statically, you don't get to look only at the closefrom syscall, you need to consider all attributes of all of them.

In other words, I don't want to depend on glibc's closefrom at all. (It's just a shallow wrapper around the syscall after all.) I just want to make use of kernel functionality when it's available and I'm interested in advice on whether this is a reasonable idea.

No, it is not a reasonable idea.

The purpose of the system call wrapper functions is to abstract kernel details from userspace programs. This protects you from issues such as the Linux system call numbers being different for different architectures, including x86 vs. x86_64, or the occasional change in system call numbers for a given arch. It also gives you a measure of source compatibility with other systems, such as MacOs, the BSDs, and Solaris. Overall, the wrapper functions are the stable kernel interface for userspace programs.

I cannot imagine making a direct syscall without being confident that the syscall number I requested was associated with the system function I wanted. That is exactly the kind of thing that might test successfully enough to release, and then fail mysteriously and / or devastatingly in the field, probably a couple of years later, after I've forgotten all about my nasty hack.

Better solutions include:

• lowest common denominator approaches. That is, things that work on all supported machines. That you thereby forego faster alternatives available on a subset of supported machines is a cost of broad portability. If it's fast enough on machines that don't have (e.g.) closefrom(), then why do you need to make it faster on systems that do have that function? And how much speed do you really gain?

• compile-time selection. You said you want to avoid this, but there's a reason that it is the usual approach for tuning programs to the capabilities of host machines. With static linking you don't need to worry about the runtime host's C standard library, but you do need to worry about kernel version. A common approach is to provide two (or more) binaries targeting different, possibly overlapping, ranges of kernel versions.

• working around your need for the feature in the first place. For the particular case of closing files at fork / exec, you could

  • set files as close-on-exec when you open them, OR
  • register fork handlers (pthread_atfork()) as needed to close the files when the program forks. This should work even if the program's initial thread is its only one.