rtkit-daemon tries to set priorities for firefox after upgrade (68->69)
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: mmorfikov, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
I noticed that since firefox v69, rtkit-daemon tries to manage the browser priorities, and the system log gets spammed with the following messages:
rtkit-daemon[757]: Successfully made thread 4268 of process 4242 owned by '1000' RT at priority 10.
rtkit-daemon[757]: Supervising 3 threads of 3 processes of 1 users.
There are many of them, basically with each new tab opened I get bunch of ones mentioned above.
People are trying to get rid of the logs by setting LogLevelMax=notice in the systemd rtkit-daemon service, but that doesn't really solve the core problem.
When I open multiple firefox profiles, or just open many tabs, I can see another spam in the syslog saying that:
rtkit-daemon[3714]: Warning: Reached maximum concurrent threads limit for user '1000', denying request.
Moreover, I often notice system lockups:
rtkit-daemon[3812]: Recovering from system lockup, not allowing further RT threads
So allowing firefox to manipulate priorities isn't a good thing in my opinion.
Is there a way to prevent firefox from setting priorities for its processes?
I don't really want to remove rtkit-daemon (it does a nice job for services that really need to get some higher priorities, like pulseaudio).
|
||
Comment 1•6 years ago
|
||
Hi @Mikhail Morfikov, I've tried to test the issue on the Ubuntu fedora 12, but I have a problem accessing the syslog files (could be the environment - shouldn't be the proper one for me) in order to see if the error you've described appears in my end. Due this facts, I will add a component for it, if isn't the right one please fell free to change it & maybe someone from dev's team could give us a hand.
Regards,
Liviu
|
Reporter | |
Comment 2•6 years ago
|
||
It looks like rtkit-daemon grants access via policykit, and in the case of rtkit there are 2 actions:
org.freedesktop.RealtimeKit1.acquire-real-time
org.freedesktop.RealtimeKit1.acquire-high-priority
Firefox wants acquire-real-time and PulseAudio wants acquire-high-priority . So I can temporary block the acquire-real-time action, since nothing else except firefox uses it, and at the same time PulseAudio will get its priority without a problem. But still it's just a temporary fix.
Same problem here on Arch Linux
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0
|
||
Comment 4•6 years ago
|
||
If I read Firefox code correctly, calls to rtkit-daemon in Firefox starts from [1]. Apparently Firefox calls rtkit-daemon unconditionally for AudioIPC-related threads.
There is another bug report about rtkit-daemon [2], which matches the date of the aforementioned commit.
[1] https://github.com/mozilla/gecko-dev/commit/88c421c259299bd0e2fe1de41857565dee7cfc54
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1560811
|
||
Comment 5•6 years ago
|
||
On recent Firefox (current release), this is better, and only promotes threads as needed. The code linked in comment 4 is very old. I'm closing this, let me know if there are other issues.
Description
•