reassign 507248 jackd thanks On Sat, Mar 07, 2009 at 02:47:37PM +0100, Adrian Knoth wrote:
> First: I'm going to reassign this bug to libpam-modules, since > /etc/security/limits.conf isn't owned by jackd. > Second: There's usually no need to limit the size of the maximum locked > memory. Actually, some programs (ardour?) even print a warning if you do > so. Then ardour should be fixed. Why are *any* of these applications screwing around with locked memory? The purpose of locked memory is to have a secure memory area that will never be written to disk in the swap space. Sound applications should *not* be second-guessing the kernel's memory management by using mlock for performance reasons! The default memlock limit exists to prevent DoS attacks against other users on the system. You can't have more locked memory than you have physical memory, so if one user can lock all the physical memory, then the other users get none, even if there's additional virtual memory still available. Anyway, if you disagree with the default limits, you need to take that up with kernel upstream. My policy for libpam-modules is that our defaults need to match the kernel defaults - the place to set policy on limits is in the kernel, not in PAM. > Third: with realtime prio, I've never seen the need for special nice > levels, so there's probably no use (but danger) in including a > nice-line. Anyway, I'm not an expert in this field. > Suggestion: add these two lines to limits.conf: > @audio - memlock 0 > @audio - rtprio 99 > IIRC, that's what Ubuntu does. No, Ubuntu doesn't do this. Anyway, if there are per-user or per-group limits policies that packages need to apply, you can do that by adding your own conffile to the (non-existent by default) /etc/security/limits.d/ directory, as described in the pam_limits(8) manpage. Removing the memlock limit is still wrong. That needs to be fixed in whatever app is abusing locked memory this way. Setting the rtprio for a dedicated group is reasonable. Care should be taken to ensure that, any time the package setting this limit is installed, the group being referenced exists and is the group that you think it is. The best way to accomplish this is by getting consensus that the group should be added statically to base-passwd; if not, then you should discuss this on debian-devel and create the group in your package's maintainer script. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
