Description
Since sccache will be invoked as a generic compiler wrapper, in some situations it might be invoked with pretty exotic file descriptors. For instance, nobody stops me from doing this in a Bash shell, even if it's somewhat questionable:
$ exec 4<> /tmp/a.c # Open /tmp/a.c as file descriptor number 4 in Bash
$ sccache /usr/bin/gcc -o /tmp/executable -x c /dev/fd/4 # sccache will inherit fd 4, so this will work
$ exec 4>&- # Close file descriptor 4 in Bash
One of the tasks of the compiler wrapper is to spawn a sccache server when one is not already running. When starting a background process we want as little baggage from the original process as possible, and extra file descriptors are an instance of such baggage that can lead to unexpected problems.
A notorious example of such problems is that ninja will get stuck if executing the sccache wrapper in a tty, because ninja uses a covert pipe to detect when its subprocesses finish execution when sharing a console (!): ninja-build/ninja#2444
You can probably imagine other scenarios in which the daemon accidentally sharing some file descriptors may cause problems.
daemonize (the crate used for most of the setup of spawning the server process) unfortunately does not handle this except for the standard discriptors (stdin, stdout, stderr), and it couldn't without breaking compatibility as a daemon may still need to share specific file descriptors in specific situations.
Nowadays you can use something like close_range() (FreeBSD. Linux 5.9, glibc 2.34). Other approaches involve using /proc/<PID>/fd or similar mechanisms to figure out and close extraneous file descriptors.