[LAU] The Many Ways of Pam Limits...

[Brent Busby]

Looking at the various sources online giving advice about setting up 
realtime pre-emption in /etc/security/limits.conf, I found this mildly 
amusing list of recommendations from various sources.  I've changed the 
group to 'realtime' in all cases just because that's what I use.

# Gentoo:
*              hard    rtprio          0
*              soft    rtprio          0
@realtime      hard    rtprio          20
@realtime      soft    rtprio          10

# Gentoo (Pro-Audio Overlay):
@realtime      -       rtprio          90
@realtime      -       nice            -5
@realtime      -       memlock         500000

# Arch:
@realtime      -       rtprio          70
@realtime      -       nice            -10
@realtime      -       memlock         250000

# Suse:
@realtime      -       rtprio          100
@realtime      -       nice            -10
@realtime      -       memlock         400000

# Debian:
@realtime      -       rtprio          99
@realtime      -       nice            -15
@realtime      -       memlock         250000

# Ubuntu:
@realtime      -       memlock         0
@realtime      -       rtprio          99

# Jack:
@realtime      -       rtprio          99
@realtime      -       memlock         unlimited

# Alsa:
@realtime      -       rtprio          95
@realtime      -       memlock         512000
@realtime      -       nice            -19


Hey, with concensus like this, how can you go wrong!  :)

These are the main questions this brought up for me:

- Hard and soft limits:  Most of these examples don't set separate hard
   and soft limits for anything, with the exception of the generic Gentoo
   realtime docs at the top.  Since the soft limit is defined in the
   kernel.org documentation for pam_limits as "default values, for normal
   system usage", does this mean that if my account is in a group that
   sets a "soft" rtprio of 10 as shown in that example, that every
   process I launch gets that setting?  A program with such permission
   still has to specifically request realtime, doesn't it, even with this
   "default"  soft limit being present?  It makes it kind of meaningless
   if your text editor, your desktop clock, and your file manager can all
   get that priority too automatically just because it's a "default", or
   so I'd guess anyway...

- For most of the other examples, the '-' symbol is being used to set
   the hard and soft limits to be the same.  Presumably this makes the
   "default for normal system usage" as sky-high as the maximum, as in
   the cases where a rtprio of 99 and unlimited memory locking is shown.
   This makes me think (hope?) even more that this is something an app
   needs to specifically request by asking the kernel for realtime, even
   under an account that has the PAM permissions!

- Many sources actually say in their accompanying texts that allowing a
   negative niceness is not necessary, and thus do not.  Others set a
   mild one ('-5' in the Gentoo Pro-Audio Overlay), and some like the
   Alsa Project documentation recommend scary-looking ones like '-19'
   that seem bound to get in the way of kernel services, if I'm not
   misinterpreting.  How "not nice" should we allow a recording app to
   get?  Or are the sources that don't set this on the right track?

- Memlock is fairly self-explanatory to me.  I'd presume you want to
   allow an app to memlock as much resident space as you expect your
   largest pro-audio app to take.  I was wondering if there was anything
   to fear from non-pro-audio apps though in cases where the setting was
   "unlimited".  This seems a possible loss of stability should one of
   your desktop programs go crazy for some reason...or is this, again,
   something that a program would have to request via a special call to
   the kernel, which wouldn't be likely from random errant behavior?
   What I'd really like to be able to do is run Qsampler/LinuxSampler
   with very large Gigasampler format libraries, and have it work well.
   I have 8GB of memory on my system, so should I memlock say 4-6GB or
   so?

The common factor in all these questions is:

Do these abilities have to be requested by a process through an 
extraordinary call the kernel, or does this open your whole desktop up 
to rampant memory usage, process priority elevation, etc. all the time? 
I'd mainly like only my pro-audio apps to make use of these abilities, 
even if I do grant them to my user account.

-- 
+ Brent A. Busby	 + "We've all heard that a million monkeys
+ UNIX Systems Admin	 +  banging on a million typewriters will
+ University of Chicago	 +  eventually reproduce the entire works of
+ Physical Sciences Div. +  Shakespeare.  Now, thanks to the Internet,
+ James Franck Institute +  we know this is not true." -Robert Wilensky