Lost control over ulimit max lock size and rtprio

[Anton Gubarkov]

I run jack and ardour for more than 4 years already and the machine was perfectly set up for this scenario.

Then I noticed that jack and ardour started to complain about not being able to lock enough memory.
So I checked and found to my surprise:

Code: Select all

anton@PF16W6Y2 ~ $ ulimit -l -r
max locked memory           (kbytes, -l) 256
real-time priority                  (-r) 99

anton@PF16W6Y2 ~ $ cat /etc/security/limits.d/40-realtime-base.conf
# Start of 40-realtime-base.conf from realtime-base-0.1

@realtime	-	rtprio	99
@realtime	-	memlock unlimited

# End of 40-realtime-base.conf from realtime-base-0.1

I also checked my systemd config:

Code: Select all

anton@PF16W6Y2 ~ $ cat /etc/systemd/user/40-audio-limits.conf
[Manager]
#DefaultLimitNICE=
DefaultLimitRTPRIO=95
DefaultLimitMEMLOCK=1073741824

So I wonder how I can re-gain control of my ulimit parameter?

[Dominique_71]

I was having a similar issue with rtprio being lower than in /etc/security/40-audio.conf (openrc system). It was caused by a lower rtprio in another file in that directory. The user was inheriting both settings (the 'groups' command was helpful to find which settings was in use) and the lowest one was applied last and in use. I edited the conf file to get the same settings in both files.

[Anton Gubarkov]

I was able to track down this problem to pipewire that installed the file into /etc/security/limits.d with limitation on locked memory using the range of uids. apparently the range of uids has precedence over groups.
I raised a bug to gentoo devs to fix it.

[artbody]

i found this page
https://www.systutorials.com/docs/linux ... er.conf.d/

and so i solved this problem
20-pw-defaults.conf

Code: Select all

# This file was installed by PipeWire project for buffer locking to always work

# Required to memlock audio buffers for all client types
#
# This will match all PAM users i.e. those going through the login procedure but
# it should not get applied to system daemons, since they are run bypassing PAM.
#
# While at first glance this might appear very relevant, in fact abusing this
# can at most allow for either more rapid OOM or enhance malicious system memory
# thrashing while evading systemd-oomd limits that are based on the requirement
# that swap utilization must be high before issues arise. As such it's perfectly
# reasonable to just set a limit where each client can lock a few megabytes with
# nearly no impact on regular systems. Meanwhile malicious attackers can OOM
# just as they could. And instead tooling for OOM and resource abuse should be
# improved, if such denial of service attacks are a serious consideration at all.
#
# Starting with Linux 5.16 or systemd v253 the default is 8192 which is plenty
# good enough and this file should not be installed on such systems.
#*         - memlock  8194
*         - memlock  unlimited

same in
25-pw-rlimits.conf