What makes it possible for a `pulseaudio' process to get the nice level of -11?

Question

I noticed that a pulseaudio process on my Gentoo Linux machine has the nice level of -11. But I don't know how it has gained such a high priority regardless of being owned by a normal user.

I know a non-root user can launch a program only with a lower priority than 0 with the nice command, and it says "Permission denied" if we try to give a process a higher priority than 0.

Because the pulseaudio process is owned by me (a non-root user), I think it cannot get such a high priority without any special treatment.

So, my question is what "treatment" does enable pulseaudio to have a low niceness value.

Answer 1

PulseAudio requires higher priority than other desktop programs mainly to avoid latency problems and get a skip-free audio playback. But the process that allows PulseAudio to have a higher priority is rather complex.

To get this special priority, it uses the RealtimeKit (rtkit-daemon) process. This D-Bus service allows some user programs to use real-time scheduling and enforces some strict policies to prevent abuse:

• Only clients with RLIMIT_RTTIME set will get RT scheduling.
  • RLIMIR_RTIME: Specifies a limit on the amount of CPU time that a process scheduled under a real-time scheduling policy may consume without making a blocking system call
• RT scheduling will only be handed out to processes with SCHED_RESET_ON_FORK set to guarantee that the scheduling settings cannot 'leak' to child processes, thus making sure that 'RT fork bombs' cannot be used to bypass RLIMIT_RTTIME and take the system down.
  • SCHED_RESET_ON_FORK: If set this will make sure that when the process forks a) the scheduling priority is reset to DEFAULT_PRIO if it was higher and b) the scheduling policy is reset to SCHED_NORMAL if it was either SCHED_FIFO or SCHED_RR.
• Limits are enforced on all user controllable resources, only a maximum number of users, processes, threads can request RT scheduling at the same time.
• Only a limited number of threads may be made RT in a specific time frame.
• Client authorization is verified with PolicyKit.

[...] it includes a canary-based watchdog that automatically demotes all real-time threads to SCHED_OTHER should the system overload despite the logic pointed out above. For more information regarding canary-based RT watchdogs [...]

More related information:

• RealtimeKit and the audio problem
• RealtimeKit announcement on the LAD (Linux-Sound) list
• PulseAudio set_scheduler(int rtprio) function source that implements this

Answer 2

@zuazo's answer is very informative for pulseaudio specifically. For completeness, I'll note that in the general case, there are four circumstances that can cause a process not owned by root to have a high priority:

1. The program being run is setuid-root, and gave itself the high priority and then changed its uid.
2. The process has the capability CAP_SYS_NICE (and may or may not have dropped it after giving itself high priority).
3. The process was given high priority by another process which was either running as root or had the CAP_SYS_NICE capability.
   • This is the case that applies to PulseAudio as described by the other answer. You can also run sudo renice to give any process a higher priority.
4. The process is a child of another process which already had a high priority, and did not have SCHED_RESET_ON_FORK set.

There are other subtleties: when you say a process is "owned by" you, you may be talking about the real UID or the effective UID - the effective UID determines whether it is root for the purpose of being able to give itself high priority, whereas the real UID is how it knows what UID to change back to after doing so.