Increase FD limits to let Steam Play works reliably

(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.


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!


Quelle surprise. :roll_eyes:


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?


I tested this parmeter even before this topic was created (see post #11)

//Tested with following kernel and parameters
Kernel 4.14
Kernel 4.18
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_osi=! acpi_osi=\"Windows 2009\" acpi_backlight=vendor video.report_key_events=0"
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_osi=! acpi_osi=\"Windows 2009\" video.report_key_events=0"
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_osi=! acpi_osi=\"Windows 2009\""

DefaultLimitNOFILE=1048576  = backlight change is very laggy
DefaultLimitNOFILE=524288   = backlight change is a bit less laggy
#DefaultLimitNOFILE=1048576 = no more lag (see first character of line :D)

// That's the output of journalctl when I change backlight
sept. 03 09:56:36 yo-gs pkexec[27959]: pam_unix(polkit-1:session): session opened for user root by (uid=1000)
sept. 03 09:56:36 yo-gs pkexec[27959]: yo: Executing command [USER=root] [TTY=unknown] [CWD=/home/yo] [COMMAND=/usr/lib/gsd-backlight-helper --set-brightness 62]

If I change backlight with xorg-xbacklight I got no more bug,
that's why I think it's related to the way /usr/lib/gsd-backlight-helper work or maybe pkexec.
The "laggyness" increase as DefaultLimitNOFILE increase,
that's why I think it's related to DefaultLimitNOFILE

Not relevant.
I don’t understand how the initial reporter you came to this fd limits upower <-> backlight connection.

Not less than yours at least, and I did not ask for revert, just for .pacnew files:

You convinced me your report is real. And I'm not here to argue so I apologize if I came off as attacking you. I just wanted to understand how one user can affect the entire distro's update process.

As for your original problem, did you ever try this?

1 Like

Seems to be the same solution (ignore keystroke from videobus) at an other level, it should work, I never thought of doing it that way thanks for the hint. But we are going off topic, it's an other issue :sweat_smile:.

pamac install

1 Like

Is it possible to have a new package called steamplay-manjaro which carries only the configs needed to run Steam Play out of the box? This way people will continue installing only steam-manjarofor Steam, and add up this new package if he wants to stay on the edge? This new package can be added as an optional dependency to steam-manjaro.

IMHO seems the best of both worlds, lets us easy circumscribe the issues related to the changes and make all users happy! :slight_smile:

It looks like the post above yours is the resolution. It puts the increased limits back in place and backs up the files as @Yoy0 requested.


@ziabice steam-manjaro with the increased limits is currently in unstable.

BTW, there is a typo in the config. Limits is misspelled in the comment.

@korealinux thanks for the info, actually I decided to stay with steam-manjaro- stable, avoiding the -3 update

What is the first number designating?

Soft limit vs. hard limit.

1 Like

Forum kindly sponsored by