Troubles increasing (soft) open file limit

Ask Fedora
1

Hello everyone, first post here, loving Fedora :saluting_face:

I might need some collective insight on the issue I’ve been having. Think I’m having troubles understanding open file limits (I’m a newbie in Linux in general). The original issue I’ve been having is intermittent Plasma crashes on F41 - either the panels freeze while the system overall (open apps and such) is working, or the whole system crashes. Been troubleshooting this and noticed this line in Journal:

user@1000.service The Wayland connection experienced a fatal error: Too many open files

So I did some reading on open file limits to see if it helps. My ulimit -a output is as follows:

real-time non-blocking time (microseconds, -R) unlimited
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 127304
max locked memory (kbytes, -l) 8192
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 127304
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

And my ulimit -Hn is 4096 (after some tweaking I did).

Now, whatever I do I cannot get the ulimit -n to increase from default 1024 to 4096 and actually stick. If I run ulimit -n 4096 it will apply the new limit but it won’t stick and gets returned to 1024 at some seemingly random point without even rebooting the system.

After reading some guides online I’ve applied some changes:

  1. Edited /etc/security/limits.conf to include this:
    (*) soft nofile 4096
    root soft nofile 4096

  2. Created a .conf file in /etc/security/limits.d/ with the same entry from above;

  3. Created system.conf and user.conf files in /etc/systemd/, both with DefaultLimitNOFILE=4096

Yet the file limit keep returning to 1024 and Plasma still crashes from time to time. Now the questions I have:

  1. I suppose some of the above workarounds are not applicable, but what should I do instead?
  2. Is it even the right solution for these crashes/freezes I’ve been experiencing?

I’m somewhat new to Linux distros in general so don’t kick me please :grinning_face_with_smiling_eyes:

As for other useful info: running Fedora 41 KDE spin, Nvidia 4070 GPU on 570 drivers. Kinda suspect that the GPU may be the culprit as it usually is with Nvidia’s lame drivers: Fd leak with explicit sync and kde plasma - #14 by shelter - Linux - NVIDIA Developer Forums

Edit: I’ve done some digging on the Nvidia leak above and it seems like this is indeed the culprit - I can reliably crash Plasma by repeatedly opening app launcher or switching desktops which spams sync files as checked with lsof -p $(pidof plasmashell). Now it means that increasing the limits won’t help it, only delay the crash, but still curious why I fail to change it persistently. Meanwhile gonna wait till Nvidia fix their stuff :roll_eyes:

2

Hi R.B.,

Welcome to Fedora!

Try making those entries in /etc/security/limits.conf like the following, reboot and see how things look:

* soft nofile 4096
* hard nofile 8192

NOTE that these are VERY conservative values. I usually set mine to this:

* soft nofile 32000
* hard nofile 64000
2 Likes
3

Did you also add a line containing [Manager] above that DefaultLimitNOFILE= line?

Also, from man systemd.exec:

LimitNOFILE=
Don’t use. Be careful when raising the soft limit above 1024, since select(2) cannot function with file descriptors above 1023 on Linux. Nowadays, the hard limit defaults to 524288, a very high value compared to historical defaults. Typically applications should increase their soft limit to the hard limit on their own, if they are OK with working with file descriptors above 1023, i.e. do not use select(2). Note that file descriptors are nowadays accounted like any other form of memory, thus there should not be any need to lower the hard limit. Use MemoryMax= to control overall service memory use, including file descriptor memory.

1 Like
4

I used to run this one-liner for Wine that took ulimit -Hn from default 524288 to 1048576:

sudo mkdir -p '/etc/systemd/system.conf.d' '/etc/systemd/user.conf.d' && echo -e "[Manager]\nDefaultLimitNOFILE=1048576" | sudo tee '/etc/systemd/system.conf.d/nofile.conf' > '/dev/null' && echo -e "[Manager]\nDefaultLimitNOFILE=1048576" | sudo tee '/etc/systemd/user.conf.d/nofile.conf' > '/dev/null' && cat '/etc/systemd/system.conf.d/nofile.conf' '/etc/systemd/user.conf.d/nofile.conf'
2 Likes
5

Hi, thanks for the info! Interestingly enough, this has adjusted my hard limit but the soft limit remains at 1024. I’m not aware of what could cause it but it seems like this value is being set by something overriding these limits.

But you know, since the thread I mentioned kinda confirms the bug somewhere within Nvidia-Wayland-Plasma interaction, and taking into account the info provided by @glb, I think I’d better leave these limits alone. Will try to look for the solution for that sync file spam though :saluting_face: