I’ve installed rtcqs and tried to address every issue, but some still fail:
$ uv tool run rtcqs
rtcqs - version 0.5.3
Root User
=========
[ OK ] Not running as root.
Audio Group
===========
[ OK ] User finotti is in the audio group.
CPU Frequency Scaling
=====================
[ OK ] The scaling governor of all CPU's is set at performance.
Kernel Configuration
====================
[ OK ] Valid kernel configuration found.
High Resolution Timers
======================
[ OK ] High resolution timers are enabled.
Tickless Kernel
===============
[ OK ] System is using a tickless kernel.
Preempt RT
==========
[ OK ] Kernel 6.13.7-1-siduction-amd64 is using threaded IRQ's.
Spectre/Meltdown Mitigations
============================
[ OK ] Spectre/Meltdown mitigations are disabled. Be warned that this makes your system more vulnerable to Spectre/Meltdown attacks.
RT Priorities
=============
[ WARNING ] Could not assign a 80 rtprio SCHED_FIFO value due to the following error: [Errno 1] Operation not permitted. Set up limits.conf. See also https://wiki.linuxaudio.org/wiki/system_configuration#limitsconfaudioconf
Swappiness
==========
[ WARNING ] vm.swappiness is set to 60 which is too high. Set swappiness to a lower value by adding 'vm.swappiness=10' to /etc/sysctl.conf and run 'sysctl --system'. See also https://wiki.linuxaudio.org/wiki/system_configuration#sysctlconf
Filesystems
===========
[ OK ] The following mounts can be used for audio purposes: /
[ WARNING ] The following mounts should be avoided for audio purposes: /run/user/1000/doc. See also https://wiki.linuxaudio.org/wiki/system_configuration#filesystems
IRQs
=====
[ OK ] Soundcard snd_hda_intel:card0 with IRQ does not share its IRQ.
Soundcard snd_hda_intel:card0 with IRQ does not share its IRQ.
Soundcard snd_hda_intel:card0 with IRQ does not share its IRQ.
Soundcard snd_hda_intel:card0 with IRQ does not share its IRQ.
Soundcard snd_hda_intel:card0 with IRQ does not share its IRQ.
Soundcard snd_hda_intel:card1 with IRQ 101 does not share its IRQ.
Soundcard snd_hda_intel:card2 with IRQ 102 does not share its IRQ.
Power Management
================
[ OK ] Power management can be controlled from user space. This enables DAW's like Ardour and Reaper to set CPU DMA latency which could help prevent xruns.
As discussed here, it seems that the place to add memlock settings is in /etc/security/limits.d/25-pw-rlimits.conf. I have:
# 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 95
@pipewire - nice -19
@pipewire - memlock unlimited
Any ideas why it is still failing the sanity check?
You’ve set up the pipewire group to have realtime privileges (@pipewire - rtprio 95) but have you added your user to that group?
If the groups command doesn’t say “pipewire”, among other things you should run usermod -a -G pipewire yourUserName as root to add your user to that group and then log out and back in again.
Or replace @pipewire with just your user name.
Once you’ve done that you can run ulimit -r and it should say “95”.
The check verifies that your user account is part of the audio group.
It seems that pipewire installation creates a pipewire group, not an audio group.
Note the comment in the pw-rlimits file:
I see “sid” in the kernel name, does that imply you are running Debian Unstable?
Information I found indicates that the installation does create the pipewire group, so likely you just need to make your user part of that group, as Peder Hedlund indicated.
Is your user in the pipewire group. run id in a terminal.
have you rebooted or re-logged in after creating the file /etc/security/limits.d/25-pw-rlimits.conf?
$ uv tool run rtcqs
rtcqs - version 0.5.3
Root User
=========
[ OK ] Not running as root.
Audio Group
===========
[ OK ] User finotti is in the audio group.
CPU Frequency Scaling
=====================
[ OK ] The scaling governor of all CPU's is set at performance.
Kernel Configuration
====================
[ OK ] Valid kernel configuration found.
High Resolution Timers
======================
[ OK ] High resolution timers are enabled.
Tickless Kernel
===============
[ OK ] System is using a tickless kernel.
Preempt RT
==========
[ OK ] Kernel 6.13.7-1-siduction-amd64 is using threaded IRQ's.
Spectre/Meltdown Mitigations
============================
[ OK ] Spectre/Meltdown mitigations are disabled. Be warned that this makes your system more vulnerable to Spectre/Meltdown attacks.
RT Priorities
=============
[ WARNING ] Could not assign a 80 rtprio SCHED_FIFO value due to the following error: [Errno 1] Operation not permitted. Set up limits.conf. See also https://wiki.linuxaudio.org/wiki/system_configuration#limitsconfaudioconf
Swappiness
==========
[ WARNING ] vm.swappiness is set to 60 which is too high. Set swappiness to a lower value by adding 'vm.swappiness=10' to /etc/sysctl.conf and run 'sysctl --system'. See also https://wiki.linuxaudio.org/wiki/system_configuration#sysctlconf
Filesystems
===========
[ OK ] The following mounts can be used for audio purposes: /
[ WARNING ] The following mounts should be avoided for audio purposes: /run/user/1000/doc. See also https://wiki.linuxaudio.org/wiki/system_configuration#filesystems
IRQs
=====
[ OK ] Soundcard snd_hda_intel:card0 with IRQ does not share its IRQ.
Soundcard snd_hda_intel:card0 with IRQ does not share its IRQ.
Soundcard snd_hda_intel:card0 with IRQ does not share its IRQ.
Soundcard snd_hda_intel:card0 with IRQ does not share its IRQ.
Soundcard snd_hda_intel:card0 with IRQ does not share its IRQ.
Soundcard snd_hda_intel:card1 with IRQ 100 does not share its IRQ.
Soundcard snd_hda_intel:card2 with IRQ 101 does not share its IRQ.
Power Management
================
[ OK ] Power management can be controlled from user space. This enables DAW's like Ardour and Reaper to set CPU DMA latency which could help prevent xruns.
So, I am not sure if I am getting false “fails” from the tests, or if there is really something wrong with my configuration. (I am unable to test in a session, as I still have to install all my plugins and restore backups of my projects. I am just trying to set it up as much as I can for now.)
Yes, indeed I am using siduction, which is virtually Debian Sid.
Ardour’s sanityCheck -hasrtlimits is a bit blunt in that it only checks for the line rtprio <some-double-digit-number> in the /etc/security/limits.conf file, whereas you have the line enabling rtprio in /etc/security/limits.d/25-pw-rlimits.conf.
You can either just ignore that check or add a comment in /etc/security/limits.conf that says
# rtprio 00
to fool it.
Not exactly sure why rtcqs complains, though, but since ulimit -r says 95 it’s probably a false error as well.
While that is indeed the canonical way. I like a little tool called prlimit.
$ prlimit
RESOURCE DESCRIPTION SOFT HARD UNITS
AS address space limit unlimited unlimited bytes
CORE max core file size unlimited 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 unlimited unlimited 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 1048576 files
NPROC max number of processes 62086 62086 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 62086 62086 signals
STACK max stack size 8388608 unlimited bytes
Another thing is that it checks for rtprio *[0-9][0-9]* , so “rtprio 00” makes it perfectly happy (IDK if pam_limits would complain about it, though).
I’d suggest removing the first “0-”
Does -hasrtlimits check that there is an audio group and that the group has rtprio in limits.conf?
From what I can see it calls system_has_rtprio_limits_conf which only checks for rtprio in limits.conf.
To find out whether there actually is an audio group you have to run -hasaudiogroup (system_has_audiogroup).
Then it’s -memberaudiogroup to see if your user is a member, but you still don’t know if it’s the audio group that has the rtprio entry in limits.conf or if it’s the pipewire or some user created my-rtprio-group that’s in limits.conf
Shoot… I rebooted the computer this morning, and now I get:
$ ulimit -r
0
or
$ 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 8388608 8388608 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 247173 247173 processes
RSS max resident set size unlimited unlimited bytes
RTPRIO max real-time priority 0 0
RTTIME timeout for real-time tasks unlimited unlimited microsecs
SIGPENDING max number of pending signals 247173 247173 signals
STACK max stack size 8388608 unlimited bytes
The /etc/security/limits.d/25-pw-rlimits.conf file is unchanged and the user is still in the pipewire group, so I am not sure why it is not being picked up.
The only thing I can think of is that I tested a new install of carla with pw-jack carla. I did not change any audio configuration (as far as I can remember).
Did you put # rtprio 00 in limits.conf to silence the sanityCheck warning?
If so, did you actually add the # at the beginning? Because if you didn’t it won’t be a comment but an actual config statement.
Later limits.d files should override anything in limits.conf (I think) but it seems like that could be something that happened.
Unless Robin is correct in his assumption above.
$ cat 25-pw-rlimits.conf
# 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 95
@pipewire - nice -19
@pipewire - memlock unlimited
No, I did not:
$ cat limits.conf
# /etc/security/limits.conf
#
#This file sets the resource limits for the users logged in via PAM.
#It does not affect resource limits of the system services.
#
#Also note that configuration files in /etc/security/limits.d directory,
#which are read in alphabetical order, override the settings in this
#file in case the domain is the same or more specific.
#That means, for example, that setting a limit for wildcard domain here
#can be overridden with a wildcard setting in a config file in the
#subdirectory, but a user specific setting here can be overridden only
#with a user specific setting in the subdirectory.
#
#Each line describes a limit for a user in the form:
#
#<domain> <type> <item> <value>
#
#Where:
#<domain> can be:
# - a user name
# - a group name, with @group syntax
# - the wildcard *, for default entry
# - the wildcard %, can be also used with %group syntax,
# for maxlogin limit
# - NOTE: group and wildcard limits are not applied to root.
# To apply a limit to the root user, <domain> must be
# the literal username root.
#
#<type> can have the two values:
# - "soft" for enforcing the soft limits
# - "hard" for enforcing hard limits
#
#<item> can be one of the following:
# - core - limits the core file size (KB)
# - data - max data size (KB)
# - fsize - maximum filesize (KB)
# - memlock - max locked-in-memory address space (KB)
# - nofile - max number of open file descriptors
# - rss - max resident set size (KB)
# - stack - max stack size (KB)
# - cpu - max CPU time (MIN)
# - nproc - max number of processes
# - as - address space limit (KB)
# - maxlogins - max number of logins for this user
# - maxsyslogins - max number of logins on the system
# - priority - the priority to run user process with
# - locks - max number of file locks the user can hold
# - sigpending - max number of pending signals
# - msgqueue - max memory used by POSIX message queues (bytes)
# - nice - max nice priority allowed to raise to values: [-20, 19]
# - rtprio - max realtime priority
# - chroot - change root to directory (Debian-specific)
#
#<domain> <type> <item> <value>
#
#* soft core 0
#root hard core 100000
#* hard rss 10000
#@student hard nproc 20
#@faculty soft nproc 20
#@faculty hard nproc 50
#ftp hard nproc 0
#ftp - chroot /ftp
#@student - maxlogins 4
# End of file
No idea what’s going on but you can try adding finotti - rtprio 94
to /etc/security/limits.conf and log out and in.
Make it 94 so you can tell the difference between it and the entry in 25-pw-rlimits.conf, if ulimit -r starts showing anything other than zero
Maybe also check the permissions for /etc/security/limits.d/ and 25-pw-rlimits.conf
I suppose only root needs to be able to read them but mine are o+r so maybe pam_limit reads them as the user logging in.
When I did this and rebooted, ulimit -r did give 94, so it seems that /etc/security/limits.conf takes priority. But after removing this line and rebooting again, I got 95.
It turns out, according to my experiments, that ulimit will return 0 when connecting the machine with SSH. Issuing the command directly on the machine does give the expected result of 95.
Thanks for your help, and my apologies for the noise…
It turns out, according to my experiments, that ulimit will return 0 when connecting the machine with SSH. Issuing the command directly on the machine does give the expected result of 95.
That rang a slight bell for me, for an issue completely unrelated to audio. A quick search revealed this StackOverflow question, where the high-score answer states:
f you just want sshd to honor the settings you made in /etc/security/limits.conf, you should make sure you have UsePAM yes in /etc/ssh/sshd_config, and /etc/pam.d/sshd lists session required pam_limits.so (or otherwise includes another file that does so).
