On 1/16/19 5:02 PM, Michael Jarosch wrote: Thanks for this.  I too am on a Debian system, so this is probably a Debian-specific problem. "ulimit" with no arguments prints the maximum file size limit, and is a synonym for "ulimit -f". To see all user limits, "ulimit -a".  "ulimit -l" just prints the maximum size of a memory locked segment in MB. The behavior you are seeing is the same as mine: the limit setting in /etc/security/limits.d/audio.conf is not being respected (assuming that the user from which you printed that transcript is in the "audio" group). 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! bg

On Thu, 17 Jan 2019 at 23:22, Bill Gribble <grib(a)billgribble.com> wrote: For the benefit of other readers, I guess that would be this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919528

On 2019-01-17 21:50:48 (-0500), Bill Gribble wrote: I think this is only a problem in the weirdly integrated gnome apps, such as gnome-terminal, which auto-launches a gnome-terminal-server.service (user service) via dbus, that applies (probably only some) systemd user service configurations or whatever. In that case you would have to overload that user service locally (e.g. ~/.config/systemd/user/gnome-terminal-server.service), adding `LimitNOFILE=<your-nofile>` [1]. This is because the user service is started below your &lt;username&gt;(a)user.service and not in the <session-number>.scope of that user. Theoretically, this approach is more flexible (as one can have many different types of services, that have different types of limits or settings or whatever, but that's a different topic). I recommend using other terminal emulators, such as termite or xterm or urxvt (as they don't depend on a systemd user service) and are started in .scope. However, if this *did apply* to all applications, it *would be* a PAM configuration problem (which might be specific to GDM), that your distribution should figure out/ would need to fix. Therefore this only marginally has something to do with systemd. There is no "systemd black magic" preventing the limits from being applied (contrary to what some others seem to believe), but rather bad design choices of gnome (of the type "one size fits all) being applied. As a sidenote: On Arch Linux we use the package 'pambase' [1], which takes care of the configuration of e.g. system-auth, system-services and I believe this functions simililarly on other distros. If you do a `grep -R "pam_limits" /etc/pam.d`, I'm sure 'pam_limits.so' will show up in some of the configuration files. I don't really use gdm/gnome anymore (other bloat reasons), but just tested my window manager and also a gnome session started from gdm and I can't reproduce your problem (limits are applied), when using another terminal emulator than gnome-terminal. Bests, David [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#Process%… [2] https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/pamba… -- https://sleepmap.de

PS: David, did you drop fstab in favour of just using systemd? As an Arch user, I just like to know how far the audio packages maintainer does go ;)! Joking apart, there is absolutely no Linux specific consensus. Actually we need an audio Linux mailing list for each distro, since the deviation between distros does increase. At least Ubuntu and Arch have got their own audio related mailing lists. In the first place not intended as what they are needed for nowadays. Nowadays those lists are also required, because Linux distros leave the path of sharing sane commonalities.

On 1/16/19 11:02 PM, Michael Jarosch wrote: If you call ulimit without any option it shows the "file size" limit (same as `ulimit -f`). only 64MB. How about ulimit -aH That lists all hard limits. Another nice tool to show all limits is prlimit Is your user in the audio group? Cheers! robin

"ulimit -a" not only prints all current settings but shows the switches to display/set each setting and the units it is using. So "ulimit -l unlimited" should set max locked mem to unlimited (both soft and hard [if root]). "ulimit -Sl unlimited" sets soft limit only. "man bash" and search for "ulimit" for more details. cheers, John

On 19/01/2019 02.29, Michael Jarosch wrote: Hard limit is the limit set by administrator (actually by a parent process with right privileges), soft limit can be freely changed by a user or application, but can never exceed the hard limit. Locking too much memory or running a rogue process with real-time priority can harm whole system, for all user, up to the point a hard reboot is needed. That is why by default no real-time priorities are allowed and locking memory is very limited. System administrator may raise the hard limit, so users (or their application) can increase the soft limit, but until they do, the application are still limited to the soft limit. In case of audio purposes the soft limit (set lower than the hard limit) doesn't matter much, as it can only be reached when application actively tries to use it – uses real time processing and locks memory for that. If we want to use that, we need the soft limit be set high-enough, probably up to the hard limit, which is set to the same value. It won't affect other legitimate application and malicious app could increase the soft limit up to the hard limit anyway. For other limits, like 'number of open files' or 'amount of memory used' the soft limit setting is more useful, as users can use that to prevent applications from misbehaving – so a memory-leaking application crashes, before whole system start lagging, or a select()-call-using aplication won't break after opening 1025th file. Those affect all applications but usually are not required to be set above usual values. Jacek