[LAU] memlock limits not set correctly?

Michael Jarosch riotsound at riotmusic.de
Thu Jan 17 15:15:29 CET 2019


Am Mittwoch, den 16.01.2019, 23:16 +0100 schrieb Robin Gareus:
> On 1/16/19 11:02 PM, Michael Jarosch wrote:
> How about
> 
>    ulimit -aH
> 
> That lists all hard limits. Another nice tool to show all limits is
> 
>    prlimit
~$ prlimit
RESOURCE   DESCRIPTION                             SOFT      HARD UNITS
AS         address space limit                unlimited unlimited bytes
CORE       max core file size                         0 unlimited bytes
CPU        CPU time                           unlimited unlimited
seconds
DATA       max data size                      unlimited unlimited bytes
FSIZE      max file size                      unlimited unlimited bytes
LOCKS      max number of file locks held      unlimited unlimited locks
MEMLOCK    max locked-in-memory address space  67108864  67108864 bytes
MSGQUEUE   max bytes in POSIX mqueues            819200    819200 bytes
NICE       max nice prio allowed to raise             0         0 
NOFILE     max number of open files                1024    524288 files
NPROC      max number of processes                14847     14847
processes
RSS        max resident set size              unlimited unlimited bytes
RTPRIO     max real-time priority                    95        95 
RTTIME     timeout for real-time tasks        unlimited unlimited
microsecs
SIGPENDING max number of pending signals          14847     14847
signals
STACK      max stack size                       8388608 unlimited bytes


> > Can someone explain the difference?
> > /etc/security/limits.d/audio.conf says:
> > 
> > @audio   -  rtprio     95
> > @audio   -  memlock    unlimited
> 
> Is your user in the audio group?
Yes, I am!

I wonder, how to extend my limits (as root or as a user) to unlimited,
manually, if limits.d/audio.conf isn't respected regarding memlock.

And as brummer pointed out: Yes, my system also uses systemd, gdm and
pam.
Often, people tell that gnome is a bad desktop for realtime audio.
Could this be the reason for it?

Greets!
Mitsch


More information about the Linux-audio-user mailing list