Increase FD limits to let Steam Play works reliably

I have a request for the steam-manjaro package.

With the launch of the new Steam Beta Client it is now possible to run Windows games directly from the Steam Linux Client using a technology called Proton (more info here: Steam Play announcement).

With the client they ship the esync patches that require higher FD limits than the one built in with Manjaro (see here: esync README).

Actually the limit is 4096, but the needed value is 1048576 (that is the same value already shipped by Debian and its derivatives).

I solved the problem creating two files, and not touching the default limits that came with the distro.
Long story short:

  1. create the directory /etc/systemd/user.conf.d/
  2. create the directory /etc/systemd/system.conf.d/
  3. create the file /etc/systemd/user.conf.d/40-fd-limits.conf and /etc/systemd/system.conf.d/40-fd-limits.conf with the following content:

40-fd-limits.conf:

# Alter FD limis: is needed by Steam Play esync
[Manager]
DefaultLimitNOFILE=1048576

If it is possible to add that to the steam-manjaro package it would be great. This will provide a smooth gaming experience out of the box to all Manjaro users.

8 Likes

Done!

https://lists.manjaro.org/pipermail/manjaro-packages/Week-of-Mon-20180820/018685.html

12 Likes

Thanks! :slight_smile:

Forgot to mention that I needed to reboot to make changes apply.

According to the esync docs, it should be possible/needed to do systemctl daemon-reexec and restart the session to apply the settings.

Which session should be restarted?

The esync docs aren’t clear about that:

On distributions using systemd, the settings in /etc/security/limits.conf
will be overridden by systemd’s own settings. If you run ulimit -Hn and it
returns a lower number than the one you’ve previously set, then you can set

DefaultLimitNOFILE=1048576

in both /etc/systemd/system.conf and /etc/systemd/user.conf. You can then
execute sudo systemctl daemon-reexec and restart your session. Check again
with ulimit -Hn that the limit is correct.

I don’t know systemd too well to state if the command systemctl daemon-reexec is the only thing needed. I only tried rebooting and that worked…

If a reboot is all that is needed I wouldn’t worry. After an update you should reboot anyway, so I don’t think it’ll cause much of an issues for anyone.

According to docs, increasing this limit has the consequence of theoretically allowing something to take more resources than it should. A fork-bomb, for example, is more effective with the higher values.

This was under discussion here:

and had not yet been tested.

In my own testing, a single file was required.

As I indicated in the other thread, this is also a request which should be made upstream, rather than implemented only by Manjaro.

But whatever. I guess we’re doing it this way now.


@ziabice Or can I assume you have tested this change on multiple systems with multiple configurations and multiple workloads to ensure it has no potential negative side-effects?

Just limit the number of user processes to something like 2000 for a desktop system. That should be enough even for a heavy desktop environment to function properly and still prevent a fork bomb killing the system.

Obviously a server should be set much lower.

EDIT: Just thought i’d add you can check how many you’re running (including threads) with:

ps -AL --no-headers | wc -l

Then obviously tweak as needed for your system.

I tried this setting 1/2days ago and it made my brightness fn shortcut behave with a 2/3sec delay :frowning_face:.
Experienced it in budgie, don’t know if other DE are affected with my laptop (MSI GS40 6QE).

1 Like

(please excuse my poor english, I’m not a good speaker, hope that something don’t get lost in translation)

Honestly, when I read the docs, I were very puzzled by the change from 4096 to 1048576. The first thing I thought was “how much memory this will consume?”, but if Debian uses this, maybe it’s not that bad.

Returning to your question: no, I haven’t tested this option on different machines and workloads, because a paid developer from Valve software maybe already did it for me. Testing is already happening now on thousand of PC running Steam Play (if you check the Steam hardware stats, Ubuntu is the main distro used with Steam).

On my PC that setting didn’t make any difference in performance or responsiveness.

Like it or not, that setting (or a more limited version of it, which I’d honestly prefer) is needed to let Steam Play works out of the box with the vast majority of games: I discovered some games that don’t work otherwise. There’s always the possibility to switch off completely the esync thing, but this requires manual intervention by the user.

The choice is: let make it work once and for all without human intervention or let the Manjaro users do the usual gimmicks.

About the fork bomb: my request is limited to Steam Play, that means that I suppose you use your PC to play games. You are not running a server, nor important services available 24h a day. With my suggestion, if you don’t have Steam, you don’t have problems. Yes, there could be some badly written software that will fork bomb, but I highly doubt it isn’t already malicious per se.

If this is a so big problem, we can create a package called this-makes-steam-play-work.tar.xz and tell people to install it as a temporary solution and with a big warning about the consequences.

4 posts were merged into an existing topic: New version of Steam Play (with Windows games support)

First regression replies occurred. Seems we should revert it.

2 Likes

BTW, the regression with backlights was unrelated to fd limits.

It’s still related to fdlimit for me and seems (need confirmation) for this guy too:



For me it is gnome’s /usr/lib/gsd-backlight-helper.
If I use xorg-xbacklight instead it’s ok but I loose backlight animation :sob:.

PS: (I’m not asking to remove the setting just to backup /etc/systemd/*.conf.d/fdlimit config file when steam-manjaro is updated (.pacnew)).

I have a hard time to understand how and why increasing FD limits would have a negative effect like described by @Yoy0.
As I understand it, this entire feature is mostly obsolete — it seems like a nice safeguard against a certain type of memory leak (namely, accidentally opening too many files which each take up a bit of your memory), or for controlling resources available for each user, but it seems like it has practically no use nowadays, when file opens have practically no cost at all on most systems.

Do I miss something here? I hope somebody can enlighten me!

2 Likes

Quelle surprise. :roll_eyes:

2 Likes

Since I’d reverted these settings in steam-manjaro, we might think off adding it to systemd package at some point. People know now on how to higher the fd-limits when needed.

Well this is disappointing. I got worried when I saw a new steam-manjaro update so soon after the one that added increased FD limits, and sure enough, it was reverted. Perhaps a bit hastily I might add.

Oh well, guess I gotta add my own files back.

Was this because of the backlight issue? It can’t be since another user even verified it was not because of fd limits. And the Arch bug report also mentions nothing about fd limits.

I don’t understand how the initial reporter came to this fd limits <-> backlight connection. The same user has previously posted about backlight issues due to a kernel upgrade. And they have modified their system to fix the issue previously ( kernel parameter video.report_key_events=0).

@Yoy0 can you please explain your testing process? Which version of upower were you running when you had this backlight problem? 0.99.8-1 or 0.99.7-1? (0.99.8-1.1 is the reversion that was pushed a few hours ago btw). Do you still have the modified kernel settings for your problem a few months ago?

From my search, video.report_key_events=0 is not a common solution to fixing backlight issues. I only see 1 reference to it on a French site which links back to your Manjaro post. Did you try recommended solutions from the Arch wiki?

In any case, there is only person on this forum or anywhere else saying it’s a fd limits problem as far as I can tell. And I find this whole situation of one person making an unverified claim which reversed system-wide changes for thousands of other users a little weird.

Or was it reverted for some entirely other reason?

5 Likes

Forum kindly sponsored by Bytemark