> > On Thu, 17 Jan 2019 at 23:22, Bill Gribble<grib@xxxxxxxxxxxxxxx> 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.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@xxxxxxxxxxxxxxxxxxxx
https://lists.linuxaudio.org/listinfo/linux-audio-user
