Should probably also warn if your Vulkan driver does not expose every extension needed (for e.x. Stream Output)
Should probably also warn if your Vulkan driver does not expose every extension needed (for e.x. Stream Output)
I think a good start would be just to warn if you do not have a vulkan driver installed in the first place (if you are using open source drivers you probably have to install them separately anyways). But this would be a topic for another request I think.
Upstream systemd is raising this limit drastically in the near future. It will take a while to end up in distros, but this will eventually more or less solve itself. https://github.com/systemd/systemd/pull/10780 Whether it's worth the effort of implementing a warning between now and then is a valid question.
The first thing to ask when considering this I think, is what distros do not use systemd, and how prevalent are they (are they worth the effort of making this specific function for?) it might also be worth considering how prevalent it is among linux users who do not like systemd manage to find ways to remove it or use those distros. (systemd has quite a sizable group of haters)
Maybe the best bet would be to look at what distros users are using the most with steam on linux, but it seems basically the only information we can gather from that is that 40% or so steam for linux users use ubuntu, and the rest use something else (not specified...). Which is a bit confusing because the steam system information thing clearly shows which distribution I am using. Maybe if you can access a more detailed description of it than "other" (49%). and kernel 4.x. (11%)
This value must be 1048576 or higher as per the instructions provided by the official esync documentation.
Ehh, it's a bit hard to pinpoint correct value just like that. Total max value supported by Linux is hardware-dependent and can be checked in /proc/sys/fs/file-max. Some older systems simply can't handle so many files open at the same time (e.g. my old Thinkpad X220 can handle max 382104, while much newer desktop with 16GB of ram can handle 1606949).
I think it's enough to leave a warning in log file if esync for particular game is enabled and hard limit is set too low. It might be good idea to print all current user limits as info to log file in any case.
@Rabcor systemd is extremely prevalent amongst desktop Linux users at this point. When you'll look at protondb stats, at least 92% of Proton users are on distro, that uses systemd by default. Remaining 8% are all on "Unknown" - I can't calculate exact percentages at the moment, but these "Unknown" distros are e.g. Parrot, Pop!_OS, Sabayon, Solus, SteamOS, openSUSE or Zorin (all using systemd).
The only 4 distros, that do not use systemd by default that I see in report dumps are Void Linux, Gentoo, Funtoo and Slackware (I doubt all together they constitute more than 1% of Proton users).
And for all other distros: If users figure out how to hate systemd enough to replace it by something else, they are sure smart enough to figure out problems resulting from this. Because after all, removing systemd solves a lot of problems for them. ;-) Or in other words: If you move away from the distro defaults that far, you're on your own. Nobody needs to support that.
But a question: Does it hurt older system if the hard limit is raised that much? Shouldn't it just stop working if esync tries to use more than is supported?
BTW: Gentoo is actually not only non-systemd. It depends on the system profile you're using. It can support systemd out-of-the-box very well. Funtoo as a derivate is probably similar.
Agreed. Games that have been whitelisted could very well freeze due to file descriptor limitation, as pointed out here.
Still, that's just one thing Helldivers does suffers from. The other, which is multiplayer, could work by symlinking libgnutls.so.30 to Pinned_libs folders, but that no longer works. So yeah, having a game which relies on libgnutls in order to play multiplayer is still something Proton/Steamplay hasn't got to work just yet :-/
@aeikum why was this closed? Has this issue somehow been resolved? Or just determined best left unsolved?
I was going through closing old issues that won't be acted on. Systemd raised the default limit and we haven't seen users running into this issue in a long time. If you're still encountering a low limit, you should raise the issue with your distribution.
I've just had an issue come up on Alpine Linux (a non-systemd distribution) which could have been prevented by this. While I do know that it's an issue that could have been avoided had I simply used a supported distribution, I would like to point some facts out in favor of a warning being implemented anyway:
I think at the very least this potential issue could be mentioned in the Wiki where a very similar issue on the same level is already described, the issue being vm.max_map_count being set too low by the kernel and some distributions for some modern games.
It seems that this was fixed in 9.0-3:
Added a warning that appears in Proton Log for systems that have low file descriptor limit (e.g. non-systemd distributions).
Yes :D I forgot to update this issue, so thank you! @rudolf-enum Thank you for bringing it to our attention again :)
Feature Request
Proton uses Esync, Esync (and even without it, many games) requires the ability to open many files at the same time. The default file descriptor limit in some distributions is too low for Esync and Proton should be able to detect that and warn the user about it.
See: https://github.com/zfigura/wine/blob/esync/README.esync
I confirm:
contain this feature already.
Description
There's a hard and soft open file limit, the soft limit can be set low, but the hard limit needs to be high. You can check to see what your hard limit is with the ulimit -Hn command (does not require root). This value must be 1048576 or higher as per the instructions provided by the official esync documentation.
Proton should be able to check whether the value is appropriately high, and warn the user if it is not.
Justification [optional]
Most users will not know about this setting or it's importance, and it being misconfigured might lead to issues even with whitelisted games.
Risks [optional]
None