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 .
Experienced it in budgie, don't know if other DE are affected with my laptop (MSI GS40 6QE).
(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
If I use
xorg-xbacklight instead it's ok but I loose backlight animation .
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!
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.
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
@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: pam_unix(polkit-1:session): session opened for user root by (uid=1000) sept. 03 09:56:36 yo-gs pkexec: 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
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?
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 .
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
IMHO seems the best of both worlds, lets us easy circumscribe the issues related to the changes and make all users happy!
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.