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 1369197 - memlock limit set too low in etc/security/limits.d/95-jack.conf
Summary: memlock limit set too low in etc/security/limits.d/95-jack.conf
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: jack-audio-connection-kit
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Brendan Jones
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-08-22 15:46 UTC by J. Bruce Fields
Modified: 2016-10-31 01:58 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-10-31 01:58:41 UTC


Attachments (Terms of Use)

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.


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