User no longer has rtprio and memlock after upgrading to F40

Ask Fedora
, , , ,
1

After upgrading to Fedora 40 and I noticed when I run rtcqs I see that I no longer have rtprio and memlock for my user. This also became an issue when I launched Ardour.

/etc/security/limits.conf was blank so I added the proper entries back in and rebooted:

@audio - rtprio 90 # maximum realtime priority
@audio - memlock unlimited # maximum locked-in-memory address space (KB)

My user is currently in the following groups: wheel, audio, realtime, docker, vboxusers, pipewire.

I tried creating a new “test” user as well and added them to the audio group and realtime group, but no luck.

Does anyone know if rtprio and memlock are now read from a different file/location in F40?

2

Specifically related to the content of the /etc/security/limits.conf file (and .conf files placed in /etc/security/limits.d/)
Did you read the man page for the limits.conf file?
It tells you what goes in that file and what it means. The 2 values you mention are specifically listed for that file.

In the /etc/security/limits.d/25-pw-limits.conf file I see this

# This file was installed by PipeWire project for its libpipewire-module-rt.so

# It is up to the distribution/user to create the @pipewire group and to add the
# relevant users to the group.
#
# PipeWire will fall back to the RTKit DBus service when the user is not able to
# acquire RT priorities with rlimits.
#
# If the group is not automatically created, the match rule will never be true
# and this file will have no effect.
#
@pipewire   - rtprio  70
@pipewire   - nice    -19
@pipewire   - memlock 4194304

I suspect that since your user is a member of pipewire those limits should apply. Without looking at the code for rtcqs it seems a potential bug in the code.

3

Hi @computersavvy

Thanks for the reply. I don’t believe there is an issue with rtcqs, as what it is telling me appears valid.

Running ulimit -a showed that max locked memory (the -l option) is not unlimited. Also Ardour notified me of the change in privileges immediately:

image

my 25-pw-limits.conf looked exactly like you mentioned.

I reverted back to 39 last night (which was surprising painless with timeshift, only grub needed updating), but I plan to install f40 in a VM today and see if I can replicate the issue on a fresh install vs. an upgrade.

4

@computersavvy

Quick update: on a fresh VM, I encountered the same issue, but figured it out.

Changed memlock from 4194304 to unlimited in 25-pw-rlimits.conf. The pipewire file appears to take precedence over the realtime.conf file for memlock.

@pipewire   - rtprio  70
@pipewire   - nice    -19
@pipewire   - memlock unlimited

realtime.conf has the following

@realtime       soft    cpu             unlimited
@realtime       -       rtprio          99
@realtime       -       nice            -20
@realtime       -       memlock         unlimited

ulimit -a now shows the following:
image

In all honesty, it doesn’t look like I would need the realtime.conf file anymore as long as the user is in the pipewire group.

Crisis averted :grinning: