Bug 1369197

Summary: memlock limit set too low in etc/security/limits.d/95-jack.conf
Product: [Fedora] Fedora Reporter: J. Bruce Fields <bfields>
Component: jack-audio-connection-kitAssignee: Brendan Jones <brendan.jones.it>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: brendan.jones.it, nphilipp, oget.fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-31 01:58:41 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description J. Bruce Fields 2016-08-22 15:46:22 UTC
95-jack.conf sets the memlock limit to 4194304, but I'm finding that jack (started with qjackctl) and amsynth are requesting about 10M.  We want by this to work by default out of the box.  Simplest might just be to bump that memlock limit?

(Also, the soft limit setting seems to be ignored, see bug 1366880.)

Comment 1 Orcan Ogetbil 2016-09-04 14:41:29 UTC
(In reply to J. Bruce Fields from comment #0)
> 95-jack.conf sets the memlock limit to 4194304, but I'm finding that jack
> (started with qjackctl) and amsynth are requesting about 10M.  We want by
> this to work by default out of the box.  Simplest might just be to bump that
> memlock limit?

Sure, we can do that. But where exactly is the 10M request made? On my system, qjackctl simply invokes:
   /usr/bin/jackd -dfirewire -r44100 -p512 -n3

> (Also, the soft limit setting seems to be ignored, see bug 1366880.)

I don't observe this behavior:
   $ ulimit -r
   70
   $ ulimit -l
   4194304
Probably some other setting is interfering.

Comment 2 J. Bruce Fields 2016-09-07 21:53:15 UTC
(In reply to Orcan Ogetbil from comment #1)
> (In reply to J. Bruce Fields from comment #0)
> > 95-jack.conf sets the memlock limit to 4194304, but I'm finding that jack
> > (started with qjackctl) and amsynth are requesting about 10M.  We want by
> > this to work by default out of the box.  Simplest might just be to bump that
> > memlock limit?
> 
> Sure, we can do that. But where exactly is the 10M request made?

I don't know, I just saw "Cannot lock down 107335194 byte memory area (Cannot allocate memory)" in qjackctl's "Messages" window.  Grepping through ps, I see
"/usr/bin/jackd -dalsa -dhw:0 -r48000 -p1024 -n2".  I don't think I've fooled with any defaults here.

> On my
> system, qjackctl simply invokes:
>    /usr/bin/jackd -dfirewire -r44100 -p512 -n3
> 
> > (Also, the soft limit setting seems to be ignored, see bug 1366880.)
> 
> I don't observe this behavior:
>    $ ulimit -r
>    70
>    $ ulimit -l
>    4194304
> Probably some other setting is interfering.

Huh.  This was a new install of F24.  Again, I don't think I changed any defaults, though it's possible I've forgotten something.

Comment 3 Orcan Ogetbil 2016-09-09 02:55:14 UTC
Okay, I sense a bit of confusion here (including myself).
First, 107335194 bytes is about 100MB, not 10MB.
Second, the ulimit value of 4194304 is given in terms of kilobytes, see "man ulimit". So this value is about 4GB.

I don't think the problem is with the size of this number. It seems to me that the setting is being ignored on your machine. 

The bug #1364332 is about this error. Which desktop environment are you using, gnome? Did you try KDE for example?

Comment 4 J. Bruce Fields 2016-09-09 15:11:28 UTC
(In reply to Orcan Ogetbil from comment #3)
> Okay, I sense a bit of confusion here (including myself).
> First, 107335194 bytes is about 100MB, not 10MB.
> Second, the ulimit value of 4194304 is given in terms of kilobytes, see "man
> ulimit". So this value is about 4GB.

Whoops, apologies, you're right.

> I don't think the problem is with the size of this number. It seems to me
> that the setting is being ignored on your machine.

OK, so maybe the only bug is 1364332.

My memory is that I also had to fool with those limits, though, so maybe I'm still missing something.  So before closing, I'll investigate some more.  And maybe see if I can find a way to test this on a fresh install.

> The bug #1364332 is about this error. Which desktop environment are you
> using, gnome?

Right, Gnome--I try to stick to defaults to the extent possible.

> Did you try KDE for example?

No, though I can see ulimits are as expected in a text console, see https://bugzilla.redhat.com/show_bug.cgi?id=1366880#c3.

Comment 5 Orcan Ogetbil 2016-09-22 03:08:10 UTC
Is it okay to close this as a duplicate to bug 1364332?

Comment 6 J. Bruce Fields 2016-09-22 13:27:27 UTC
This bug was about the limits being poor defaults, bug 1364332 is about the limits not being set at all.

As you point out, I was confused about the units, so may simply has been wrong (in which case we should close this as NOTABUG), but first could we give it a little longer and see if I can find the time to reproduce the problem I thought I saw?

Comment 7 Orcan Ogetbil 2016-09-23 02:54:28 UTC
sure, let us know.

Comment 8 J. Bruce Fields 2016-10-31 01:58:41 UTC
OK, I give up figuring out what I saw before.  Apologies--I agree the bug should just be closed.