Re: Xorg bug returns: Too many files open in system

[Sergey Bugaev]

Hello,

I investigated briefly and found this piece of code to be the likely
culprit [0]. I also see that the previous investigation also arrived
at the same conclusion [1].

[0]: 
https://gitlab.gnome.org/GNOME/vte/-/blob/db3c6253d7fa1645996a2abd9fd55df414ca4c2d/src/missing.cc#L218
[1]: https://lists.gnu.org/archive/html/bug-hurd/2021-01/msg00136.html

It looks like the corresponding piece of code in glib [2] is now a
little bit more robust: it uses a fallback fd limit, and ignores
possible errors (however rare it is that ignoring errors makes you
more robust...), since not being able to set cloexec is hardly fatal
(in a non-security sensitive context).

[2]: 
https://gitlab.gnome.org/GNOME/glib/-/blob/ce093edcc589654dbb44bf1a4f365467dce6483e/glib/gspawn.c#L1509

I'm also somewhat surprised that glibc doesn't provide close_range ()
natively. That doesn't sound too complex to implement either,
something like this should work, right?

int
__close_range (unsigned int first, unsigned int last,
               unsigned int flags)
{
  int i;

  if (first < 0 || first > last)
    return __hurd_fail (EINVAL);
  if (flags & ~CLOSE_RANGE_CLOEXEC)
    return __hurd_fail (EINVAL);

  HURD_CRITICAL_BEGIN;
  __mutex_lock (&_hurd_dtable_lock);

  for (i = first; i <= last && i < _hurd_dtablesize; i++)
    {
      struct hurd_fd *fd = _hurd_dtable[i];

      if (fd == NULL || fd->port.port == MACH_PORT_NULL)
        continue;

      __spin_lock (&fd->port.lock);

      if (flags & CLOSE_RANGE_CLOEXEC)
        fd->flags |= FD_CLOEXEC;
      else
        {
          _hurd_port_set (&fd->ctty, MACH_PORT_NULL);
          _hurd_port_locked_set (&fd->port, MACH_PORT_NULL);
        }

      __spin_unlock (&fd->port.lock);
    }

  __mutex_unlock (&_hurd_dtable_lock);
  HURD_CRITICAL_END;

  return 0;
}

Sergey