Red Hat Bugzilla – Bug 428056
error message: System policy prevents PulseAudio from aquiring high-priority scheduling
Last modified: 2008-03-12 22:27:30 EDT
Description of problem:
When login in into kde4 an error message is shown with the following text.
System policy prevents PulseAudio from aquiring high-priority scheduling
An application is preventing to perform an action that requires privileges.
Authentification as the super user is required to perform this action.
Password for root: _____
This error disappears after some time during the login before I'm able to take
a screenshot. You've also have to disable kde splash screen at all to see the
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Login into kde
2. start systemsettings and disable splash screen
3. re-login into kde
no error message
W: polkit.c: Failed to show grant dialog: Did not receive a reply. Possible
causes include: the remote application did not send a reply, the message bus
security policy blocked the reply, the reply timeout expired, or the network
connection was broken.
W: polkit.c: PolicyKit responded with 'auth_admin_keep_always'
N: main.c: Called SUID root and real-time/high-priority scheduling was
requested in the configuration. However, we lack the necessary priviliges:
N: main.c: We are not in group 'pulse-rt' and PolicyKit refuse to grant us
priviliges. Dropping SUID again.
N: main.c: For enabling real-time scheduling please acquire the appropriate
PolicyKit priviliges, or become a member of 'pulse-rt', or increase the
RLIMIT_NICE/RLIMIT_RTPRIO resource limits for this user.
E: main.c: read() failed: Inappropriate ioctl for device
E: main.c: daemon startup failed.
I've filed this against kdebase because of phonon. When we've figuret out what
really happens we could re-assign it.
That's not a KDE bug nor even KDE-specific, it's the PolicyKit policy which is
to ask this pointless question. This issue has already been discussed on the
mailing list, I can't find an existing bug report though. (I searched the
PolicyKit and pulseaudio bugs and found nothing.) As discussed there, PolicyKit
should answer "yes" or "no" there (I'd lean towards always saying "yes", but
I'm not an expert on the matter), either is better than this annoying dialog
The fact that the dialogbox disappears before an answer can be given is another
bug, probably also in PolicyKit.
(In reply to comment #1)
> The fact that the dialogbox disappears before an answer can be given is another
> bug, probably also in PolicyKit.
And, actually, if you bothered to learn what PolicyKit you would discover that,
surprisingly, it's a only mechanism. FWIW, I've already asked Lennart to avoid
using PolicyKit in this rather silly way. Lennart?
*** Bug 430558 has been marked as a duplicate of this bug. ***
This is an issue in fc9-alpha1
OK this broke more with the lastest set of fc9-alpha1 updates.
Now isntead of one of these screens I get three in a row.
Ajax has removed this for now.