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.)
(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.
(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.
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?
(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.
Is it okay to close this as a duplicate to bug 1364332?
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?
sure, let us know.
OK, I give up figuring out what I saw before. Apologies--I agree the bug should just be closed.