|Product:||[Fedora] Fedora||Reporter:||J. Bruce Fields <bfields>|
|Component:||gdm||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||24||CC:||bfields, rstrode, tmraz|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2016-08-23 14:48:35 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description J. Bruce Fields 2016-08-14 02:21:11 UTC
Description of problem: jack-audio-connection-kit installs a file etc/security/limits.d/95-jack.conf which raises rtprio and memlock limits to give users in the jackuser group better latency for audio work. However, after installing jack-audio-connection-kit, adding myself (bfields) to jackuser, and then rebooting and logging in, I still see: $ ulimit -r 0 $ ulimit -l 64 instead of the limits set in 95-jack.conf: @jackuser - rtprio 70 @jackuser - memlock 4194304 I'm on Fedora 24, with pam-1.2.1-5, jack-audio-connection-kit-1.9.10-5. Bug 754285 says that global limits set in limits.conf and limits.d are ignored now, but that per-user limits should still be effective.
Comment 1 J. Bruce Fields 2016-08-20 02:09:29 UTC
(In reply to J. Bruce Fields from comment #0) > $ ulimit -r > 0 > $ ulimit -l > 64 Actually, the hard limits are set as requested in 95-jack.conf: $ ulimit -Hr 70 $ ulimit -Hl 4194304 it's the soft limits that aren't--I wonder why not, the "-" in limits.conf is supposed to set both. Still, the practical effect is that jack fails to get realtime priority by default until you realize you need to manually raise the soft limits first, which isn't quite the works-out-of-the-box behavior that was aimed for here. (One other nit: the jackd (or qjackctl?) defaults seem out of sync with the limits set in 95-jack.conf: jackd started with qjackctl is trying to lock about 10M.)
Comment 2 Tomas Mraz 2016-08-22 14:46:06 UTC
If you try to login on text console is the behaviour the same? I do not think this is regression in pam but something must be overwriting the soft limits on your system. As for the insufficient lock limit - report that against jack-audio-connection-kit.
Comment 3 J. Bruce Fields 2016-08-22 15:49:26 UTC
(In reply to Tomas Mraz from comment #2) > If you try to login on text console is the behaviour the same? No, the limits are respected in that case--I logged in on a text console, and found the soft limits set to what was requested in 95-jack.conf. > I do not think this is regression in pam but something must be overwriting > the soft limits on your system. That sounds plausible. So it's something that affects gnome logins but not logins on the text console. > As for the insufficient lock limit - report that against > jack-audio-connection-kit. OK, done, see bug 1369197.
Comment 4 Tomas Mraz 2016-08-23 09:46:34 UTC
I am going to reassign to gdm for further investigation on who is modifying the soft limits.