FS#46058 - [jack] [jack2] limits set too high in 99audio.conf

Attached to Project: Community Packages
Opened by Michał Zegan (webczat) - Friday, 21 August 2015, 20:25 GMT
Last edited by David Runge (dvzrv) - Tuesday, 05 February 2019, 11:53 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Ray Rashif (schivmeister)
David Runge (dvzrv)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Hello.

This bug report affects standard limit restriction configuration in /etc/security/limits.conf and /etc/security/limits.d/99-audio.conf, the last one added by installing jackd2:
First, limits.conf contains rules giving members of group audio possibility to use some realtime priorities, high nice levels and to do memlocking.
But, jackd2 (not sure about jackd) installs it's own limit file that gives the unlimited memlock permissions and unlimited realtime priority range.
Because pulseaudio gets it's realtime priority and higher nice levels using rtkit, jack seems to be the only sound server that really needs such permissions, so I think that rules in /etc/security/limits.conf should be removed, especially that jack does not use negative nice settings.
In addition, as jackd uses realtime priority 10, I think that the allowed rt priority for group audio should be decreased from 99 to 10.
For your information, the default settings cause problems with skype that for some weird reason gains realtime priority 15 (higher than jack) and nice level probably -10, interfering with pulseaudio.
This task depends upon

Closed by  David Runge (dvzrv)
Tuesday, 05 February 2019, 11:53 GMT
Reason for closing:  Fixed
Additional comments about closing:  The realtime-privileges package decouples the rtprio and memlock settings from the audio group and jack/jack2 packages by introducing the realtime group for this specific use-case.
Comment by Matthias Dienstbier (fs4000) - Monday, 31 August 2015, 07:55 GMT
Affected package is pam. We add 5 lines to limits.conf. Please distribute limits.conf unmodified. I have removed these lines on my system years ago and had no problems. jack and jack2 have their own limits.d/99-audio.conf.
Comment by Evangelos Foutras (foutrelis) - Saturday, 14 November 2015, 14:29 GMT
The relevant configuration has been dropped from limits.conf in pam 1.2.1-3 (as part of  FS#47052 ).

Reassigning to the JACK packages for the "limits set too high in 99audio.conf" issue.
Comment by Ray Rashif (schivmeister) - Monday, 16 November 2015, 05:34 GMT
This default setting is from http://jackaudio.org/faq/linux_rt_config.html and a long history of proven performance. The high limits are not specific to jackd -- any realtime thread including those for devices/IRQs can be assigned an rtprio. There may be non-audio devices that go up to 50, 70 and 99 ensures you can keep your real-time stuff always on top.

I have not had reports or complaints until now about the memory and privilege limits but in the name of security I am willing to cap sane defaults, such as an rtprio of 50 or 70, and a memlock of 500MB. This can then be edited by serious audio users, but in that case I have to once again also provide post-(install|update) messages.
Comment by Ray Rashif (schivmeister) - Sunday, 15 October 2017, 12:56 GMT
Now that I take a look at this again I realize it's more than a valid concern. Chances are a lot of folks are in the audio group and might come across weird behaviour as described in this report for Skype. The path of least resistance is to simply enforce a 'realtime' group and no longer deal with the audio group for such things. But then again I'm sure people will start to become confused (those who were already used to the audio group).
Comment by David Runge (dvzrv) - Thursday, 21 December 2017, 15:59 GMT
@schivmeister: I'd also advocate a 'realtime' group.
This should be no issue, if it is documented well before the switch.
Comment by Ray Rashif (schivmeister) - Saturday, 23 December 2017, 07:54 GMT
I agree, especially with our new mailing lists these things can be easily communicated. We'll have to decide on how best to proceed in terms of packaging, hooks or not for creating the group, or metapackage.
Comment by David Runge (dvzrv) - Tuesday, 05 February 2019, 11:52 GMT
The realtime-privileges package now establishes the 'realtime' group, which (after adding the user to it) enables the user to use aforementioned limits.
Binding to the 'audio' group (and the jack/jack2 packages) has been removed. Additionally, it should be noted, that the audio group potentially lost its meaning (on Arch), as it is not required for permissions to devices below /dev/snd/* (udev takes care of that using ACLs now) and might even be counter-productive, as it apparently prevents user-switching.
Please note, that any settings in /etc/security/limits.conf will be superseeded by drop-in configurations in /etc/security/limits.d/ (in case you have something setup in /etc/security/limits.conf).

It should also be noted (regarding the initial report), that jackd might try to use rtprio 10 by default, but the application can use higher (up to the defined limit) rtprio, using the '-P' flag and additionally IRQs might have to be set to higher priorities as well, to allow proper operation on e.g. firewire or USB audio devices (see the setup of rtirq for an example on how).
Therefore, no, the rtprio should not be decreased to 10.
However, 99 turned out to also be unsafe, as this might compete with kernel processes (e.g. watchdog, migration run at 99), which is why the max rtprio as setup in the realtime-privileges package has been decreased to 98.
To allow `memlock unlimited` for the 'realtime' group might be a little YOLO, but it is also impossible to set a "sane default" there (as machines obviously have varying amount of RAM). The system admin can of course always choose a different value for it though!

Loading...