Bugzilla – Full Text Bug Listing
|Summary:||Raise default file descriptor limits to meet Valve Proton requirements|
|Product:||[openSUSE] openSUSE Distribution||Reporter:||Daniel Noga <noga.dany>|
|Component:||Basesystem||Assignee:||systemd maintainers <systemd-maintainers>|
|Status:||RESOLVED WONTFIX||QA Contact:||E-mail List <qa-bugs>|
|Priority:||P3 - Medium||CC:||astieger, fbui, josef.moellers, lubos.kocman, mbenes, tiwai|
|Found By:||Community User||Services Priority:|
|Marketing QA Status:||---||IT Deployment:||---|
Description Daniel Noga 2018-09-06 17:58:07 UTC
Valve released beta version of Proton / Steam play. Next Leap 15.1 should meet minimal requirements. One of them is file descriptor limits: https://github.com/zfigura/wine/blob/esync/README.esync "If you get something like "eventfd: Too many open files" and then things start crashing, you've probably run out of file descriptors. esync creates one eventfd descriptor for each synchronization object, and some games may use a large number of these. Linux by default limits a process to 4096 file descriptors, which probably was reasonable back in the nineties but isn't really anymore. (Fortunately Debian and derivatives [Ubuntu, Mint] already have a reasonable limit.)"
Comment 1 Daniel Noga 2018-09-06 18:00:43 UTC
If it is possible, it will be even better to apply new limits to Leap 15.0
Comment 2 Andreas Stieger 2018-09-07 09:08:28 UTC
Similar to bug 1012494, also see https://build.opensuse.org/request/show/446360 Just this time it is this setting: > # - nofile - max number of open file descriptors This is a configurable item, and the intention of the limit should be weighed against usability. I guess we could leave the soft limit as is and raise the hard limit.
Comment 3 Josef Möllers 2018-09-12 08:00:16 UTC
Shouldn't this, then, be changed in the kernel: ./include/uapi/linux/fs.h:#define INR_OPEN_MAX 4096 /* Hard limit for nfile rlimits */ PAM has no setting for nofile in /etc/security/limits.conf. But I'm wondering: if a single package needs a bigger value, why doesn't it change the limit upon installation?
Comment 4 Daniel Noga 2018-12-02 14:35:21 UTC
Not sure, if it is the same configuration option, but it looks like it was raised in systemd 240 according to this article: https://www.phoronix.com/scan.php?page=news_item&px=systemd-240-Features-So-Far
Comment 5 Daniel Noga 2020-02-08 17:52:14 UTC
Retested in 15.2, it is still valid
Comment 6 Lubos Kocman 2020-03-03 15:10:16 UTC
Would this really be kernel Takashi?
Comment 7 Daniel Noga 2020-06-29 13:33:00 UTC
I am not an expert, but according to Valve documentation and Phoronix blog site it looks like it can be changed both on kernel and on systemd. Systemd change can be maybe better, because it is only backport from upstream systemd 240
Comment 8 Miroslav Beneš 2020-11-13 13:57:22 UTC
What is really the problem here? I took my Leap 15.2 default installation and "ulimit -Hn" indeed shows 4096 (TW has a much bigger default). It can be easily changed in systemd configuration files and the github link from the description even shows how. So I'm wondering...
Comment 9 Daniel Noga 2020-11-13 14:18:21 UTC
(In reply to Miroslav Beneš from comment #8) > What is really the problem here? I took my Leap 15.2 default installation > and "ulimit -Hn" indeed shows 4096 (TW has a much bigger default). It can be > easily changed in systemd configuration files and the github link from the > description even shows how. So I'm wondering... Yes, workaround exists and works for me. But it is not expected to need to read github, when someone want to play some game on Steam. If I need to install some enterprise Oracle or SAP, I expect tunings could be needed before it runs, but not for this. Both upstream and downstream agreed, that higher limit is better. openSUSE Leap is probably the last distribution with low defaults.
Comment 10 Miroslav Beneš 2020-11-13 14:30:54 UTC
I was not talking about workarounds. It is a configuration issue in my opinion. Yes, the defaults may be different, but that is for someone else to decide. Not a kernel issue. I am not sure which component is the correct one, so changing back to Basesystem.
Comment 11 Franck Bui 2020-12-16 07:37:25 UTC
(In reply to Daniel Noga from comment #9) > Both upstream and downstream agreed, that higher limit is better. openSUSE > Leap is probably the last distribution with low defaults. Unfortunately we can't change such default without taking the risk to break existing apps which is not acceptable if it's done via a regular update. And yes this already happened in the past when we upgraded TW with systemd v244, see bsc#1165351. So until Leap 15.3 is released, I can see only 3 options: - you can temporarily use systemd devel package for 15.3 (based on v246) until Leap 15.3 is released . Please note that the hard limit of nofile was "only" bumped to 524288 whereas Valve recommends a value of 1048576. - if Proton is started via a service, ask to Valve for bumping "LimitNOFILE=" in the relevant unit file. - if Proton is supposed to be started from the shell and is packaged, then the package might ship a drop-in in /etc/security/limits.conf.d/ to bump nofile otherwise if it's not packaged you should temporarily use this solution until Leap 15.3 is out.  https://build.opensuse.org/package/show/home:fbui:systemd:SLE-15-SP3/systemd
Comment 12 Daniel Noga 2021-01-11 20:02:57 UTC
To me, updated systemd for 15.3 seems good enough solution. 524288 is probably enough, Lutris promotes that value: https://github.com/lutris/docs/blob/master/HowToEsync.md Proton is not started as a service and that value affects Proton/Wine and applications using it so at least Lutris/Steam. So solution upgrade to upstream value for system looks better, than set this for every wine/proton application. Unfortunatelly I cannot properly test it now, for now it works for me even with the low value 4096 and I don't know why... What now? Mark it as Leap 15.3 and set status to Resolved?
Comment 13 Franck Bui 2021-01-12 14:49:49 UTC
(In reply to Daniel Noga from comment #12) > What now? Mark it as Leap 15.3 and set status to Resolved? Given the fact that you seem fine to use systemd from 15.3, I would say so.
Comment 14 Franck Bui 2021-01-26 15:32:20 UTC
OK let's assume that the fact that Leap 15.3 will fix this is enough for now. Hence closing this as WONTFIX since the bug was opened against Leap 15.2.