On Thu, 06 Jun 2024 at 15:21:22 +0200, Marco d'Itri wrote:
> On Jun 06, Luca Boccassi <bl...@debian.org> wrote:
> > The last time this was tried some packages were still not ready, so it
> > was patched out to let them be fixed.
>
> I missed the venerable inn 1.x at the time, and I never noticed that it
> allocates some data structures for all available fds. Apparently this
> worked well enough for 1M file descriptors, but not for 1G. :-)
>
> The solution was easy enough:
> https://salsa.debian.org/md/inn/-/blob/master/debian/patches/limit_getfdcount
I believe the change Luca describes is increasing rlim_max (hard limit)
but not rlim_cur (soft limit), and the code touched by that patch is
looking at rlim_cur, so it should be unaffected anyway - unless some larger
component is raising rlim_cur.
Raising rlim_cur is also a problem for anything that relies on select(2),
which can only represent the first 1024 fds (based on FD_SETSIZE).
In (sufficiently) legacy-free code that can promise that it only uses more
scalable mechanisms like poll/epoll, close_range, and dynamically-sized
data structures, getting the benefit of this change requires locally
raising rlim_cur to match rlim_max, like e.g. dbus-daemon does.
However, if programs that raise the soft limit run subprocesses that are
outside their control, then they should also drop rlim_cur back to 1024
for those subprocesses, like dbus-daemon does for activated services.
smcv
