System does not allow realtime for the current user

Installation & Configuration Linux
#1

I just updated to version 7.3 and got the following message (which I had never seen before):

System failed the quick sanity check... Looking for the cause

System does not allow realtime for the current user... Looking for a solution

!!! WARNING !!! - The current user can not execute realtime processes.
This will adversely affect audio latency.
This system has an audio group and the user is a member. If jack was
just installed, a simple log out/in may fix this.

For best results, please correct this on your system.
(Hint: check /etc/security/limits.conf or /etc/security/limits.d/)

Here is my /etc/security/limits.d/audio.conf:

# Provided by the jackd package.
#
# Changes to this file will be preserved.
#
# If you want to enable/disable realtime permissions, run
#
#    dpkg-reconfigure -p high jackd2

@audio   -  rtprio     95
@audio   -  memlock    unlimited
#@audio   -  nice      -19

I thought that was the correct content (at least according to How do I configure my linux system to allow JACK to use realtime scheduling? | JACK Audio Connection Kit).

Is there something different with 7.3 or do I need to change anything?

#2

Start a Terminal and run
groups ; ulimit -r
You should see that you are in the audio group and that your rtprio is 95.
If not it may be as simple as logging out and in again, to applying the audio.conf settings to your user

#3

Thanks for the reply!

I do get that the user is in the audio group and that rtpio is 95. But both were already true during the update, so I am wondering why the Ardour installer gave me the message above. Is it a problem with the installer or with my system?

#4

If you’re only getting this message from the installer, I wouldn’t worry about it. I used to get messages from the installer that Jack was missing even thought that was not true.

#5

The installer did not change with this release and that particular test has not changed in years.

The installer runs a small program to just check and see if it can create a realtime process. It would be interesting to run it on your system again and see if it still fails.

You can run the command from a terminal.

/opt/Ardour-7.3.16/bin/sanityCheck -a

Your Ardour version may be different, so you will need to adjust the path to suit.

Todd

1 Like
#6

Thanks for the reply, @tnaugle!

I get “failed”:

$ /opt/Ardour-7.3.0/bin/sanityCheck -a

Sanity Check Failed!

It passes memlock and freqscaling, but fails rt and -hasrtlimits.

Any ideas of what could be wrong?

#7

-rt preforms a pretty simple test. It just tries to elevate the current process to a real time thread (SCHED_FIFO) at the minimum priority.

If that fails, then it seems like your system did not allow it, and the test is correct.

Why that is, I don’t know. You could run an old installer just to see if it also fails.

What Linux are you running?

NOTE: -hasrtlimits is not used by the installer and fails on your system because it is looking for “/etc/security/limits.conf”

#8

I am running (basically) Debian Sid/Unstable with a custom kernel.

I have that file, but all lines are commented out…

I just tried and had the same warning. So something must have changed in my computer some how…

If anyone has any pointers on how to address the issue, I’d greatly appreciate it.

#9

Did you compile the kernel or did you get it from somewhere else?
Copy in /boot/config- and we can help verify that you have the right config options to enable RT scheduling. Perhaps you inadvertently disabled that.

#10

I did not compile it, it is slh’s kernel (which has always worked great).

$ uname -a
Linux debian 6.1.0-10.slh.1-aptosid-amd64 #1 SMP PREEMPT_DYNAMIC aptosid 6.1-13 (2023-02-07) x86_64 GNU/Linux

Thank you very much for taking the time to help!

Here is the boot config file.

#11 
PREEMPT_DYNAMIC aptosid 6.1-13 (2023-02-07) x86_64 GNU/Linux

PREEMPT_DYNAMIC is a new kernel feature and it may not behave in the way that older kernels have. Although this may change over time, I don’t believe from the little I have read that this kernel configuration option is ready for mainstream use just yet. I could be wrong.

#12

I also notice this difference between your config and the config on my machine:
CONFIG_RT_GROUP_SCHED=y

My kernel does not have CONFIG_RT_GROUP_SCHED set.

I believe that config option brings cgroups into the RT permissions. I may be wrong about that, some pages I have found indicate that cgroup limiting RT scheduling would only be a problem for system services, not for user software.

The config option which Paul mentioned is for changing between none/voluntary/preempt config at boot time, but according to this article it will default to preempt, so should be the same as compiling with CONFIG_PREEMPT defined if you do not change the kernel command line.
Phoronix dynamic preempt article

That was two years ago, so I don’t know how new I would consider that feature. I guess it depends on how conservative you are with your kernel choices. It is set on my kernel config, and I did not even realize my distribution (Fedora) had switched to setting that config option, so I don’t think it has been very problematic.

I just had a few minutes to search through cgroup information, I did not find anything definitive. I cannot say with much confidence that will be a useful path to search, just that it is the only difference which stands out from my config, which does allow my applications to request RT scheduling.

#13

Thanks Paul and Chris for the informative replies.

Interesting… On the other hand, an older 6.0.0-8 version of the slh kernel also says PREEMPT_DYNAMIC, but it does pass the test.

It seems that all my recent slh kernels have this option enabled, including the version 6.0.0-8 mentioned above, that passes the check.

It seems that some change from 6.0 to 6.1 caused the change (failing the test), as older versions of 6.1 also fail.

So, my question now is: does Ardour’s test really test the systems capability or does it test for “something expected”? If the latter, I can just test it and see if it works well enough. If the former, I would likely try to find a fix.

(Well, I guess s fix is to run some other kernel… Debian’s official rt kernel passes the test as well.)

#14

I’ve been trying to determine what is going wrong with my system/kernel. (See also the discussion at LinuxMusicians.com.)

After installing rtcqs, and some fixes, the problem that still remains is

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

On the other hand, I do have have/ etc/security/limits.d/audio.conf set :

$ cat /etc/security/limits.d/audio.conf
# Provided by the jackd package.
#
# Changes to this file will be preserved.
#
# If you want to enable/disable realtime permissions, run
#
#    dpkg-reconfigure -p high jackd2

@audio   -  rtprio     95
@audio   -  memlock    unlimited
#@audio   -  nice      -19

Not only that, once (a couple of days ago) I checked rtcqs again and the RT test passed (as well as Ardour’s sanityCheck!), while I really don’t think I had done anything that would affect it.

But, after rebooting, both tests fail again.

Does anyone have any clue on what could be wrong?

#15

I have the same problem. Let’s keep this thread open until it is solved.

#16

Coincidentally I ran into a similar or maybe just this problem just a few days ago, on a new install of openSUSE Tumbleweed on Raspberry Pi 4. All set up well, but chrt not able to raise RT priorities …
I googled a while and found hints about /proc/sys/kernel/sched_rt_runtime. I set this from 950000 to -1, reloaded sysctl and chrt started to work. To make it permanent I added this line in /etc/sysctl.d/60-inotify_swappiness.conf where I keep the other suggestions from rtcqs:

kernel.sched.rt_runtime_us = -1

Funnily, on my laptops this setting is unaltered, also at 950000 and chrt works well so I really don’t know if this is of any help to you, I just wanted to add my experience…

1 Like
#17

Thanks! I haven’t be able to try it very carefully yet, but that seems to work! I googled that around and could not find the solution, so thanks for sharing!

#18

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.