[arch-proaudio] package gcr breaks real-time settings

[David Runge]

On 2018-09-02 13:41:07 (+0200), Ralf Mardorf wrote:
> On Sun, 2018-09-02 at 13:15 +0200, David Runge wrote:
> > Where exactly is that problem reported?
> An Ardour 5.8.0 window informs about the issue, when starting ardour.
> I'm not using Ardour from the repository, since I not always upgrade
> audio software during an audio production.
That means, the reporting could be faulty. 5.12 does not report that
issue. Please refer to upstream as to how stuff is reported, if this
problem persists (which I don't think it will, as it's hidden in your
setup).

> > Which are your user's groups?
> 
> $ groups
> wheel games video audio optical storage power users vboxusers wireshark
> rocketmouse vmanusers
Your user is not even in the realtime group!

> > Which is your user's default group?
> 
> $ id -g
> 1000
> $ id -gn
> rocketmouse
Seems to be unrelated then.

> > Do you have any other files in /etc/security/limits.d?
> 
> $ ls -l /etc/security/limits.d/
> total 4
> -rw-r--r-- 1 root root 45 Sep  2 11:47 10-gcr.conf
Aha!
You don't have the realtime-privileges installed to begin with.

> > What was your claimed fix?
> 
> Commenting out '@users - memlock 1024'. 
> 
> $ cat /etc/security/limits.d/10-gcr.conf 
> #@users - memlock 1024
> 
> # vim:set ft=limits:
> $ tail -2 /etc/security/limits.conf
> @audio 	- rtprio 	99
I would advice against rtprio 99

> @audio 	- memlock 	unlimited
> 
> > While all files below /etc/security/limits.d are read in C locale
> > ordering, this would mean, that 10-gcr.conf is read first and
> > 99-realtime-privileges.conf pretty much last.
> > However, neither `man 5 limits.conf` nor `man 8 pam_limits` states the
> > behavior of a user being in two different groups with diverging
> > settings. I hope that's not undefined... ;-)
> 
> So the issue seemingly is, that I use /etc/security/limits.conf and not
> /etc/security/limits.d/99-foo.conf.
>               ^^^^^^^^^^^
Yes, and your user is not in the realtime group.

10-gcr.conf is read *after* /etc/security/limits.conf, which explains
your observed behavior. The use of the plain /etc/security/limits.conf
is discouraged over the use of drop-in files in /etc/security/limits.d
anyways! Please use those!

Best,
David


-- 
https://sleepmap.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-proaudio/attachments/20180902/9d0d3aab/attachment.asc>