The last time this was tried some packages were still not ready, so itI 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
was patched out to let them be fixed. Enough time has passed now, and
it's time to let any unknown leftover just break and be fixed. In all
known cases, the buggy pattern was to manually iterate over the hard
limit and close every FD one by one, which is completely unnecessary
since kernel 5.9 (bullseye/oldstable) since the close_range() syscall
is available, that can do it in one fell swoop. Any packages still
On Jun 06, Luca Boccassi <bluca@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)Something did, because inn would start reporting ~1G available fds and
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.
On Thu, 06 Jun 2024 at 18:39:15 +0200, Marco d'Itri wrote:
Something did, because inn would start reporting ~1G available fds and
then explode, and that patch solved the issue. :-)
It might be worthwhile to try to track down what larger component did
this, because inheriting a larger rlim_cur without opt-in can also break users of select(2) as described in <https://0pointer.net/blog/file-descriptor-limits.html>.
On Jun 06, Simon McVittie <smcv@debian.org> wrote:
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.
Something did, because inn would start reporting ~1G available fds and
then explode, and that patch solved the issue. :-)
On Jun 06, Simon McVittie <smcv@debian.org> wrote:
I believe the change Luca describes is increasing rlim_max (hard limit)Something did, because inn would start reporting ~1G available fds and
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.
then explode, and that patch solved the issue. :-)
PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
bumped early at boot from 1048576 to the max value that the kernel
allows, which on amd64 is currently 1073741816.
PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
bumped early at boot from 1048576 to the max value that the kernel
allows, which on amd64 is currently 1073741816.
Hi,
It seems some proprietary software (the JetBrains IDEs) has some
problems with this change.
See for instance: https://youtrack.jetbrains.com/issue/IJPL-156522
While I wait for them to fix this on their end, what's the best way to
revert this to the original behaviour on my machine?
I would think:
echo "fs.nr_open = 1048576" > /etc/sysctl.d/99-max-fds.conf
… would do the trick, but "ulimit -Hn" reports 524288.
Something to do with DefaultLimitNOFILE=1024:524288 maybe? But
overriding that didn't work.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 339 |
Nodes: | 16 (2 / 14) |
Uptime: | 00:20:19 |
Calls: | 7,466 |
Calls today: | 2 |
Files: | 12,691 |
Messages: | 5,627,864 |