O que torna possível para um processo 'pulseaudio' obter o nível bom de -11?

Question

Notei que um processo pulseaudio na minha máquina Gentoo Linux tem o nível bom de -11. Mas eu não sei como ela ganhou uma prioridade tão alta, independentemente de pertencer a um usuário normal.

Eu sei que um usuário não-root pode iniciar um programa apenas com uma prioridade menor que 0 com o comando nice e diz "Permissão negada" se tentarmos dar a um processo uma prioridade maior que 0.

Como o processo pulseaudio é de minha propriedade (um usuário não raiz), acho que não é possível obter uma prioridade tão alta sem nenhum tratamento especial.

Então, minha pergunta é o que "tratamento" permite que pulseaudio tenha um baixo valor de gentileza.

    

Answer 1

O PulseAudio requer prioridade mais alta do que outros programas da área de trabalho, principalmente para evitar problemas de latência e obter uma reprodução de áudio sem interrupções. Mas o processo que permite que o PulseAudio tenha uma prioridade mais alta é bastante complexo.

Para obter essa prioridade especial, ele usa o processo RealtimeKit ( rtkit-daemon ). Este serviço D-Bus permite que alguns programas de usuário usem o agendamento em tempo real e impõe algumas políticas rígidas para evitar abusos:

• 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 [...]

Mais informações relacionadas:

• RealtimeKit e o problema de áudio
• Anúncio do RealtimeKit na lista LAD (Linux-Sound)
• A origem da função PulseAudio set_scheduler(int rtprio) que implementa este

Answer 2

A resposta do @azuazo é muito informativa para o pulseaudio especificamente. Para completar, observarei que, no caso geral, há quatro circunstâncias que podem fazer com que um processo que não é de propriedade do root tenha alta prioridade:

1. O programa que está sendo executado é setuid-root, e deu a si mesmo alta prioridade e depois mudou seu uid.
2. O processo tem o recurso CAP_SYS_NICE (e pode ou não ter sido descartado depois de se conceder alta prioridade).
3. O processo recebeu alta prioridade por outro processo que estava sendo executado como root ou tinha o recurso CAP_SYS_NICE .
   • Este é o caso que se aplica ao PulseAudio, conforme descrito pela outra resposta. Você também pode executar sudo renice para dar a qualquer processo uma prioridade mais alta.
4. O processo é filho de outro processo que já tinha uma alta prioridade e não tinha SCHED_RESET_ON_FORK set.

Existem outras sutilezas: quando você diz que um processo é "possuído por" você, você pode estar falando sobre o UID real ou o UID efetivo - o UID efetivo determina se ele é raiz com o propósito de poder se entregar alta prioridade, enquanto o UID real é como ele sabe o que UID mudar depois de fazer isso.