Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: The current limit on the number of processes per user in Fedora is 4096, and the limit on the number of open files per process is 1024. This causes strange redraw bugs and eventually crashes when lots of tabs are open in Chrome/Chromium, which likes to create hundreds of processes and keep open tens or hundreds of thousands of file descriptors. These crashes give no indication as to why the crashes are happening (unless the user runs Chrome from the console). It can become impossible to restore the tabs in Chrome after a crash, so you end up having to discard your entire open session just to get Chrome usable again. The frequent crashes (even with as few as 30-50 tabs) is detrimental to the experience of using Chrome on Fedora. Bug #432903 indicates that the limit on the number of processes per non-root user (nproc in /etc/security/limits.d/20-nproc.conf) was set at 1024 several Fedora versions ago "to reduce the risk of forkbombing", and was then raised from 1024 to 4096 due to an increased tendency for modern software to fork more processes. A limit of 4096 processes is still far too low for Chrome/Chromium usage on Fedora, as is an open file limit of 1024. A test with ulimits raised and 70 tabs open showed a difference of 207,000 when running "lsof | wc -l" before and after killing Chrome, an average of 3000 lsof entries per tab. Several Chrome versions ago, the V8 Javascript VM increased the number of processes it spawned by a factor of 3 or 4 per tab, causing the process limit to be hit more easily. Bug #919793 indicates that other packages have run into the low limits causing problems, and have tried manually overriding them in problematic ways when installing their own packages. Some examples of Chrome/Chromium bugs where the issue is encountered (there are probably many more): https://code.google.com/p/chromium/issues/detail?id=137875 https://code.google.com/p/chromium/issues/detail?id=169802 https://code.google.com/p/chromium/issues/detail?id=367037 https://code.google.com/p/chromium/issues/detail?id=499187 BTW the limits that are set by default don't actually mitigate an intentional forkbomb as well as intended, since they are soft limits, and the hard limits are higher. Is forkbombing even a real concern today? Needing a stable Chrome browser certainly is. Personally I set my limits really high (to 32768 or 65536 for each of file and process limits). Version-Release number of selected component (if applicable): pam-1.1.8-16 How reproducible: 100% Steps to Reproduce: 1. Run Chrome on the commandline 2. Open lots of tabs in Chrome, observe it crashing 3. Look for error messages on the console about running out of file descriptors or not being able to start a process Actual results: Chrome crashes Expected results: Users shouldn't have to know about how to raise limits themselves
PAM currently does not set the number of open descriptors limit and I do not plan to add such configuration. I will also remove the 20-nproc.conf in Rawhide as this configuration currently makes more problems than it solves.
Where does the default number of open descriptors limit come from? Is it compiled into the kernel or something?
AFAIK yes.
OK, switching component to kernel. Thanks.
We aren't changing this in the kernel source code. It's runtime tunable and can be done on a per user basis or via system wide scripts. Reassigning to the distribution component for further discussion.
If the kernel default values are not appropriate for the contemporary machines and applications, they should be changed. But of course that needs to be discussed and changed upstream.
This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23
I've dropped the 20-nproc.conf in pam-1.2.1-2.fc23. Also for the changing of the systemwide defaults if kernel is not going to change some place other than pam should be used. The limits.conf affect only the user sessions and not daemons and other services.
So, AFAICT the removal of 20-nprocconf fixes the processes issue, but the open files one is still there. pam won't ship a file to change defaults, and kernel won't change defaults from upstream. So, how can we deliver this to users? Please note I am mostly concerned about workstation, I found this bug out if frustration for my crashing chrome, but others would just blame the distro and move on.
How other distributions handle the problem with open files and chrome? I still think the current kernel default limit might be inappropriate for current applications and it should be then changed. There is no sense to have to always change it to something else in distributions.
Not sure about other distros (I use only Fedora or RHEL/CentOS :) but several hits appears with a search. The proposed solution is always tuning ulimit... On the other hand, I found these relevant issues: https://code.google.com/p/chromium/issues/detail?id=539567 https://code.google.com/p/chromium/issues/detail?id=367037 https://code.google.com/p/chromium/issues/detail?id=539590 So at least they are aware of the issue
It's worth pointing out the obvious, that ulimit can only raise the soft limit as high as the hard limit unless you're root (then you can set the hard limit). So if your system hardlimit is to low, ulimit won't help you at application launch time. Re. comment #11: yes, the first and third of those linked bugs were just barely created in the Chromium bug tracker to track the file and process limit respectively. The second bug is a dup of the first, and was already merged into it. You can see a bunch of other dups in the first bug. (I believe there would be even more dups, except that this is a maddeningly hard bug to pin down: as a tab junkie I have run into this on every Linux install I have ever used, but for years I thought it was just Chrome being buggy, and I'm sure many other people have come to the same incorrect conclusion.)
This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
May be related: https://bugs.chromium.org/p/chromium/issues/detail?id=664474#c2
This is still a daily problem for tab junkies on Fedora 24. I started using the extension "The Great Suspender" to try to limit how many tabs were active at a given time (it replaces webpage content with a lightweight placeholder page when a tab hasn't been viewed in a while), and even with this, if I have a lot of tabs open already and I open 20-30 more to research a topic, Chrome will lock up hard and then possibly crash. Curiously, if I put the following into /etc/security/limits.conf: * soft nofile 1000000 * hard nofile 1000000 * soft nproc 30000 * hard nproc 30000 ..then it sets the "ulimit -n" limit for root to 1000000, but not for a regular user (the regular user's limit is still 1024). Any idea why the regular user's limit is not affected by this? -- [For reference, the corresponding Chrome bug about reducing file descriptor usage is the following]: https://bugs.chromium.org/p/chromium/issues/detail?id=539567
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
I don't believe this bug was ever resolved for file limits -- reopening. I also wanted to point out that Chrome 67 switches on site isolation, which creates a much larger number of processes (one per open site, including for all iframes). So it is possible the process limit is going to become a problem again. https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
I am still observing crashes in Google Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=840326
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to '31'.
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle. Changing version to 31.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.