3 Nov
2005
3 Nov
'05
6:50 p.m.
Florian Schmidt wrote:
I'm a bit puzzled by this statement. lsm requires you get the patch, apply
it to your kernel, configure and compile your kernel, install and boot the
new kernel and then you can start configuring userspace to take advantage of
it.
In contrast, using the rtlimits approach can be as simple as grabbing
set_rtlimits and compiling it (assuming one has a kernel >= 2.6.13 installed
of course). Configuring userspace is via a single simple text file
(documented in the source distribution). Using it then boils down to doing
things like
set_rtlimits -r /usr/local/bin/jackd ...
set_rtlimits -r /usr/local/bin/ardour
etc when starting applications which need it. Aliases can even be used
to hide the set_rtlimits bit if desired. To me this seems a *lot*
easier than messing around with patched kernels.
It *is* true that (on systems which use PAM) PAM can be patched to provide
access to the rtlimits functionality in a transparent way. I will admit
that doing things this way is complex and a hassle. I wrote set_rtlimits
for two reasons:
1) give myself access to the rtlimits functionality - my system doesn't
run PAM, so the PAM patches aren't useful to me personally.
2) provide a much simpler way to get access to the rtlimits functionality
in this interim period until PAM (or login in the case of systems not
using PAM) support rtlimits out the box.
set_rtlimits can also control access to the rtlimit resource on a
per-program basis. A patched login wouldn't be able to do this; PAM may
or may not - I don't know enough about it to comment.
Of course everyone is free to choose the solution which best suits them;
if people prefer lsm that's fine by me.
As a side comment, I'm currently finalising a new version of set_rtlimits.
I've generalised it so it can set other resource limits too -
locked-in-memory size for example - since this can also be useful to control
on a per-program basis. Consequently its name will change to set_rlimits
but the version number will be sequential. Invocation has also been made
easier (absolute paths will no longer need to be specified - they will be
pulled from the configuration file). I expect to have time to finalise it
in the next couple of weeks.
Best regards
jonathan
since i'm
using 2.6.14 , you mean set_rtlimits from
http://www.physics.adelaide.edu.au/~jwoithe/set_rtlimits-1.1.0.tgz ?
but if i run jack as a user, there are no capture ports, and i have tons of
xruns.
Just for completeness sake: You can use the realtime lsm for 2.6.13 and
above, too. I would even recommend it, since it's much less of a hassle
to setup (rt_limits being the "correct" solution or not). 
4 Nov
4 Nov
11:01 a.m.
New subject: [linux-audio-dev] jack and setuid
Am Donnerstag, 3. November 2005 23:49 schrieb Jonathan Woithe:
I'm a bit puzzled by this statement. lsm requires you get the patch, apply
it to your kernel, configure and compile your kernel, install and boot the
new kernel and then you can start configuring userspace to take advantage
of it.
In contrast, using the rtlimits approach can be as simple as grabbing
set_rtlimits and compiling it (assuming one has a kernel >= 2.6.13
installed of course). Configuring userspace is via a single simple text
file (documented in the source distribution). Using it then boils down to
doing things like
set_rtlimits -r /usr/local/bin/jackd ...
set_rtlimits -r /usr/local/bin/ardour
yes jonathan, in my opinion its easier to set up set_rtlimits than lsm
but i thought, set_rtlimits gives me the same right as a normal user as when i
am root. right?
But on my system, when i started jackd as normal user as you wrote above.
in the config file i only changed the username into soundroom
------------------------
soundroom@funnjoy:~/src$ set_rtlimits -r /usr/local/bin/jackd -R -dalsa
jackd 0.100.0
[..] JACK compiled with System V SHM support.
cannot lock down memory for jackd (Cannot allocate memory)
loading driver ..
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
ALSA: Cannot open PCM device alsa_pcm for capture. Falling back to
playback-only mode
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for playback
JACK: unable to mlock() port buffers: Cannot allocate memory
jack main caught signal 2
no message buffer overruns
------------------------
and when i'm root evrything went better, i see my two capture devs, have no
problems with memory and whatever.
-------------------------
root@funnjoy:/home/soundroom/src# jackd -R -dalsa
jackd 0.100.0
[..]JACK compiled with System V SHM support.
loading driver ..
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for capture
nperiods = 2 for playback
jack main caught signal 2
no message buffer overruns
------------------------------------------
can someone out there tell me this hint, please
6 Nov
6 Nov
7:15 p.m.
New subject: [linux-audio-dev] jack and setuid
Hi Conrad
Not quite. Set_rtlimits gives selected programs (as configured in
/etc/set_rtlimits.conf) permission to request elevated levels of certain
resource limits, but that's all. Running something as root certainly gives
you permission to do this too, but it also enables a lot of other things
which are arguably not appropriate for audio-related software. :)
In contrast,
using the rtlimits approach can be as simple as grabbing
set_rtlimits and compiling it (assuming one has a kernel >= 2.6.13
installed of course). Configuring userspace is via a single simple text
file (documented in the source distribution). Using it then boils down to
doing things like
set_rtlimits -r /usr/local/bin/jackd ...
set_rtlimits -r /usr/local/bin/ardour
yes jonathan, in my opinion its easier to set up set_rtlimits than lsm
but i thought, set_rtlimits gives me the same right as a normal user as when i
am root. right? But on my system, when i started jackd as normal user
as you wrote above.
in the config file i only changed the username into soundroom
------------------------
soundroom@funnjoy:~/src$ set_rtlimits -r /usr/local/bin/jackd -R -dalsa
jackd 0.100.0
[..] JACK compiled with System V SHM support.
cannot lock down memory for jackd (Cannot allocate memory)
loading driver ..
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
control device hw:0
ALSA: Cannot open PCM device alsa_pcm for capture. Falling back to
playback-only mode
configuring for 48000Hz, period = 1024 frames, buffer = 2 periods
nperiods = 2 for playback
JACK: unable to mlock() port buffers: Cannot allocate memory
jack main caught signal 2
no message buffer overruns
The issues you're having here have nothing to do with set_rtlimits. In
fact, the lack of any messages associated with realtime priorities indicates
that set_rtlimits is doing exactly what it's meant to do. The problems are
related to permissions of other things.
The "cannot lock down memory for jackd" message tells you that jackd (or
more generally the user running jackd) doesn't have sufficient permission to
lock into memory the amount being requested by jackd. This is configured
using the standard resource limit mechanism provided by your system
(although for convenience the next set_rtlimits release will include support
for this resource limit too). Look for the "locked-in-memory address space"
limit, or words to that effect. If your system uses PAM it's configured
from PAM's configuration file (I can't provide further details here since I
don't use PAM). If not (eg: you run Slackware) /etc/limits (man limits) is
your friend. From memory I think I found 20MB sufficient for most of my
needs, but your mileage may vary.
The "Cannot open PCM device" means the user running jackd can't open the
ALSA device files under /dev/. You will need to arrange for
permissions/ownership of these device files to be set sufficient to allow
the jackd user to open them read-write. Many people set the group owner of
the device files to a new group which they create for the purpose ("audio"
for example) and then allow group rw access. There are many other ways,
however.
Feel free to contact me off-list for further details.
Regards
jonathan
6985
days inactive
6988
days old
linux-audio-dev@lists.linuxaudio.org
2 comments
2 participants
participants (2)
-
conrad berhörster -
Jonathan Woithe