This was originally reported on https://bugs.debian.org/1079696
When gpgconf (or any gpg process that spawns a child process) is run in a bare chroot or other constrained environment where /proc/self/fd is not available, it tries to close every file descriptor up to the maximum limit. This can take over an hour, depending on the configuration of the system.
I can confirm that this happens using libgpgerror (libgpgrt) version 1.51-3 on debian.
The source for this loop appears to be in get_max_fds in src/spawn-posix.c, which looks for /proc/self/fd but failing that walks through (in preference order, taking the first available answer):
- RLIMIT_NOFILE
- RLIMIT_OFILE
- SC_OPEN_MAX (from sysconf)
- POSIX_OPEN_MAX
- OPEN_MAX
- defaults to 256
As can be seen from the strace output in https://bugs.debian.org/1079696 , on at least some modern Debian systems, the rlim_max for RLIMIT_NOFILE is 1073741816 (0x3ffffff8 in hex), even though rlim_cur could be just 1024.
Trying to do more than a billion close() calls will make any process appear to hang indefinitely. Even if each close call takes 0.000004s (as i've measured on a modern machine) we're still talking about more than an hour spent on this loop.