Re: RFC: Realtime system (audio) group
On 01/25/2012 12:38 PM, Simon McVittie wrote:
As outlined in #656910, "being in the audio group" and "having realtime
priorities" aren't separated at the moment.
To make these two independent, we'd need to use a different (new?) group
for realtime priorities.
rtkit (packaged in Debian) seems a safer way to do this than group-based
privileges + setuid root.
As already pointed out, there is no setuid binary.
it also has a watchdog thread with a higher priority than the rt
application itself, so it can carry out an emergency de-prioritization
on the rt application to get control back to your shell/UI if the system
becomes unresponsive.
RT CPU bandwidth is limited to 95% these days. No need for a watchdog
anymore.
If you have PolicyKit, rtkit defaults to letting you have rt priorities
if and only if you are logged in locally (gdm, kdm, getty etc., but not
Is there something like
"If you're logged in locally, I'll grant you RT prios"?
that does not require the application to use dbus? So to say, "@local"
PAM magic or inherited from gdm/kdm/getty?
Can policykit do this? This would be a good compromise between "make it
work for the local user without messing with groups", but still leaving
enough freedom for the experienced if ssh is required.
Note that this would change the default ulimits if logged in locally.
We'd end up with every local user having RT priorities and more or less
unlimited memory locking. AFAIK, it's what OSX does, but it might
require some discussion if it's desired to have the same in Debian.
Cheers
Reply to: