[PlanetCCRMA] the jack permissions conundrum revisited

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Fri Jul 23 14:50:35 PDT 2010


On Fri, 2010-07-23 at 12:34 -0700, Jeff Sandys wrote:
> >> I am trying to understand this jack permissions conundrum.  You stated:
> >>
> >> > - Fedora jack1 packages allows users access to realtime
> >> > scheduling and memory locking only if the user belongs
> >> > to a particular group (jackuser?).
> >>
> >> I am not sure this is true.  When I load jack into fedora 13 from
> >> fedora repositories, jackd is in group root and all users have
> >> execution privileges.
> >
> > Easy to get confused. It is not the group of jack what matters, it is
> > the group of the user that runs jack. Jack can be executed by anyone, as
> > any other binary. But only users that belong to a certain group will be
> > able to run it with real-time scheduling.
> >
> 
> How can I figure out what group is able to run with real-time scheduling?

If you have the Fedora jack then the group should be documented in the
doc files (I think). In the /usr/share/doc/jack-audio-* directory. 

Or see which file it installed in /etc/security/limits.d/, the group
name should be there (I believe it is jackuser). 

> How can I tell if an application is using real-time scheduling?

If it is a Jack application you just need to run jack with -R, if it
does not complain about it then the clients will also be running fine
(not the whole client, just the audio processing thread). 

> >>>>snip
> >
> >> If it is just a matter of creating a jackuser group and changing
> >> jackd's group wouldn't it be easier to just create an instruction
> >> sheet or small script for those who are concerned instead of creating
> >> two versions of jack?
> >
> > This is done automatically for you when you install jack.
> >
> Would you need two separate versions of jack to achieve both the
> fedora and PlantCCRMA real-time permission schemes or could the switch
> be made with a script after installing jack (fedora-rt-mode.sh and
> ccrma-rt-mode.sh)

Both jack versions should work fine with the same real-time permission
scheme (there is a fine point with regarding to priorities we still have
to resolve). 

> I have been using the CCRMA RT kernel almost exclusively since FC8
> with no problems.  The only issues I had were with the nvidia akmod,
> but now that nouveau supports openGL direct rendering I don't need to
> worry about it.  I have had a few hangs, but I doubt that they were
> due to real-time scheduling, more likely bad laptop hardware or app
> found on the internet that I shouldn't have loaded.
> Is there a way to tell if real-time scheduling was the culprit?

You could look in the logs to see if there was something there. If it is
a hard hang the there's not much hope of anything being left behind. 

The only way to debug this (if it is repeatable) is to run the console
through a serial interface to another computer so you can look at what
happens when the computer hangs (I had to do this a couple of weeks ago
to debug a problem with the latest rt patch + autofs + nfs...)

-- Fernando




More information about the PlanetCCRMA mailing list