Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1366880 - /etc/security/limits.d/95-jack.conf ignored
Summary: /etc/security/limits.d/95-jack.conf ignored
Keywords:
Status: CLOSED DUPLICATE of bug 1364332
Alias: None
Product: Fedora
Classification: Fedora
Component: gdm
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-14 02:21 UTC by J. Bruce Fields
Modified: 2016-08-24 07:59 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-23 14:48:35 UTC


Attachments (Terms of Use)

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.

Comment 5 Ray Strode [halfline] 2016-08-23 14:48:35 UTC

*** This bug has been marked as a duplicate of bug 1364332 ***


Note You need to log in before you can comment on or make changes to this bug.