Re: [LAU] memlock limits not set correctly? - Linux-audio-user

18 Jan 2019

...
   On Thu, 17 Jan
2019 at 23:22, Bill Gribble&lt;grib(a)billgribble.com&gt;  wrote:  
  I have opened a Debian bug report against the
"libpam-modules" package
 (containing pam_limits.so, the module that actually reads and applies
 the /etc/security/limits.{conf,d} limits).  We'll see what happens!    For the
benefit of other readers, I guess that would be this one:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919528    
 That's the one.  To summarize my later findings for posterity, this 
 isn't a "bug" in libpam-modules per se but a known bad-interaction 
 between systemd and gnome.

 In short, systemd implements its own system for setting process limits 
 on login, and /etc/security/limits.* are obsolete. 
Or systemd is ugly and buggy...

...
  Here's the Link I Needed To Find:

 https://bugzilla.redhat.com/show_bug.cgi?id=1364332

 The bummer is that systemd's mechanism for setting limits is less 
 powerful than the limits.conf style and doesn't permit setting limits 
 for users based on group membership. 
More, systemd approach has changed PID1 to be similar to Microsoft Windows
svchost, break portability, ignore backwards compatibility, replace existing
services, having also many other problems...

The systemd's system for setting process limits on login is one of them.

More in general, systemd-based Linux distributions (such is Debian) are not a
good choice for audio IMO.

...
  I still haven't nailed the workaround (the ideas
in the fedora thread 
 above haven't worked, but I have little understanding of how systemd 
 manages processes so I'm sort of poking in the dark) but I will post a 
 followup to this thread when I do so that others might benefit as well.

 bg 
For me, a simply and definitive solution was upgrading from Debian to Devuan
<https://devuan.org/> (with Mate desktop -- yes, Openbox should be better, but I
did not have experimented it yet). My Linux audio DAW based on Devuan works
quite well without any change in my settings and configuration files.

Regarding the "right" value to be set as the maximum limit of RAM memory space
that can be reserved by the audio applications (memlock), it should be
appropriately "calibrated" (also at attempts) both on the basis of the memory
available in the system and the requests of the audio applications that are
used. 

Although it is possible to set this value so that it is "unlimited" or equal to
the entire RAM memory available in the system (memlock unlimited), this is not
generally advisable because it could lead (especially in the presence of
"buggy" applications) to abnormal behaviors or system blocks.

A good practice should be to use a value that is lower than the total
amount of RAM available (i.e. in systems with at least 2GB of RAM, it is
advisable to leave at least 1GB of memory "free").

Regards

-- 
al3xu5 / dotcommon
Say NO to copyright, patents, trademarks and any industrial design restrictions.