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
