]> git.ipfire.org Git - thirdparty/dbus.git/commitdiff
tests: Only check whether the first 1024 fds are close-on-exec
authorSimon McVittie <smcv@collabora.com>
Sun, 27 Oct 2024 18:19:08 +0000 (18:19 +0000)
committerSimon McVittie <smcv@collabora.com>
Mon, 28 Oct 2024 22:01:33 +0000 (22:01 +0000)
On recent Linux systems, systemd sets the hard limit on the number of
file descriptors extremely high (about 1e9, compared with about 1e6 in
previous systemd versions or 4096 in the kernel's historical defaults),
and dbus raises its soft limit to match the hard limit. The result of
sysconf(_SC_OPEN_MAX) is based on the fd limit, and iterating linearly
through that many fds takes long enough for activation to time out.

This particular piece of code is just test instrumentation, which aims to
log (possibly fatal) warnings if any file descriptor is not close-on-exec
as it should be. In practice the test suite doesn't use anywhere near
a thousand fds, so it's sufficient to run this check against a much
smaller number of fds.

Resolves: https://gitlab.freedesktop.org/dbus/dbus/-/issues/527
Bug-Debian: https://bugs.debian.org/1086148
Signed-off-by: Simon McVittie <smcv@collabora.com>
dbus/dbus-spawn-unix.c

index f3577e706e6fbad807459193f74fa27bf3dcfa5c..fa63eef47d74e9245ee046b382b38bd868095782 100644 (file)
@@ -1053,6 +1053,12 @@ do_exec (int                       child_err_report_fd,
 #ifdef DBUS_ENABLE_EMBEDDED_TESTS
   max_open = sysconf (_SC_OPEN_MAX);
 
+  /* Because fds are allocated as numerically small as possible, we don't
+   * need to check the entire fd space, which can be prohibitively slow if
+   * the fd limit is very high. */
+  if (max_open > 1024)
+    max_open = 1024;
+
   for (i = 3; i < max_open; i++)
     {
       int retval;