Anyone encountering RT Jack issues after upgrading to Ubuntu 20.04 LTS?

Ardour works fine without realtime jack, as long as you’re starting jack manually before ardour.
If you’re starting jack through ardour it has to be able to run at realtime.

What does whoami ; ulimit -r ; chrt -f 80 echo Yes RT say?

Also, what does strace chrt -f 80 true 2>&1 | grep sched_ say?

chrt: Festlegen der Richtlinie für PID 0 ist fehlgeschlagen: Vorgang nicht zulässig
In other words: Doesn’t work.
trace chrt -f 80 true 2>&1 | grep sched
sched_get_priority_min(SCHED_FIFO) = 1
sched_get_priority_max(SCHED_FIFO) = 99
sched_setscheduler(0, SCHED_FIFO, [80]) = -1 EPERM (Vorgang nicht zulässig)

Yeah, I have no idea why it doesn’t work.
If ulimit -r = 95 then chrt -f 80 should work.

It could be some weird cgroup thing but I have no idea how to troubleshoot that.

Solved. Thanks for your support, gents. I wasted a lot of time, but learned a lot :smile:

I removed an openmpi packet with an /var/lib/dpkg/ error and removed snapd which caused some apparmor issues.
So something completely different. Now everything runs as expected.

Can you tell me what you did exactly? I’m dealing with the exact same issue after a 20.04 upgrade!

I’ve completely purged snap and have disabled apparmor and still no dice.

Couple of things:
I removed snapd. Left apparmor. I had a broken package unable to repair or to remove and fixed that. I remember I removed some docker files (I forgot to mention here).
For me realTimeConfigQuickScan from github helped me finding out some issues.

I added those files to the kernel config in \boot
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_PREEMPT_RT_FULL=y
CONFIG_PREEMPT=y
I also changed CONFIG_AUDIT=n to no from yes. That was due to the fact that I got the EPERM error in:
trace chrt -f 80 true 2>&1 | grep sched
sched_get_priority_min(SCHED_FIFO) = 1
sched_get_priority_max(SCHED_FIFO) = 99
sched_setscheduler(0, SCHED_FIFO, [80]) = -1 EPERM

I also copied some files from my HDD to etc/pam.d/

If you checked ulimit -r and the other stuff Pedar mentioned it might be the first points I mentioned. Try removing docker as well I have no docker file left.

Good luck.

So I ran the reltimeconfigquickscan script and corrected all of the issues I can. my failures were the cpu governors, swapiness, max_user_watches, rtc accessability, and hpet readability. The only two still standing are teh sched_fifo limits.conf check, which I don’t get because ulimit displays unlimited memory and a 95 value for rt for my account, and “kernel with real time premption not found” which I don’t get because I’m using the same stock 20.04 kernel as you are. Here’s my current results:

== GUI-enabled checks ==
Checking if you are root… no - good
Checking filesystem ‘noatime’ parameter… 5.4.0 kernel - good
(relatime is default since 2.6.30)
Checking CPU Governors… CPU 0: ‘performance’ CPU 1: ‘performance’ CPU 2: ‘performance’ CPU 3: ‘performance’ - good
Checking swappiness… 10 - good
Checking for resource-intensive background processes… none found - good
Checking checking sysctl inotify max_user_watches… >= 524288 - good
Checking access to the high precision event timer… readable - good
Checking access to the real-time clock… readable - good
Checking whether you’re in the ‘audio’ group… yes - good
Checking for multiple ‘audio’ groups… no - good
chrt: failed to set pid 0’s policy: Operation not permitted
Checking the ability to prioritize processes with chrt… no - not good
Could not assign a 80 rtprio SCHED_FIFO value. Set up limits.conf.
For more information, see http://wiki.linuxaudio.org/wiki/system_configuration#limitsconfaudioconf
Checking kernel support for high resolution timers… found - good
Kernel with Real-Time Preemption… not found - not good
Kernel without ‘threadirqs’ parameter or real-time capabilities found
For more information, see https://wiki.linuxaudio.org/wiki/system_configuration#do_i_really_need_a_real-time_kernel
Checking if kernel system timer is high-resolution… found - good
Checking kernel support for tickless timer… found - good
== Other checks ==
Checking filesystem types… ok.
** Set $SOUND_CARD_IRQ to the IRQ of your soundcard to enable more checks.
Find your sound card’s IRQ by looking at ‘/proc/interrupts’ and lspci.

FFS looks like my upgrade didn’t include linux-lowlatency. installing now. will reboot and report.

Installing linux-lowlatency did the trick.

Note that changing values in the /boot/config file doesn’t make any difference unless you re-compile the kernel from source, using that file.

It’s just info on how the current distro kernel was compiled and it’s not referenced during boot or when the system is running.

It’s possible that the realTimeConfig scan gets some values from that file but if you’ve modified it the scan will actually lie to you.

Hi.

Hope this helps other people with the same problem.

I also had an error «Cannot create RT messagebuffer thread: Operation not permitted (1)» on jack startup. I use AltLinux, so «uninstall snap and disable apparmor» wasn’t an option for me because I haven’t snap and apparmor. Thanks to Peder Hedlund for the MWE (I slightly modified it):
chrt -f 80 echo "I'm chrt'ed!"
It helped me to localize the problem.

The solution was found at https://unix.stackexchange.com/a/284318/192507: you can just say
sudo sysctl -w kernel.sched_rt_runtime_us=-1
After this command jackd starts without errors and Ardour can open session with JACK as an audio backend.

Now can someone explain me what is happening? I just copy/pasted this command without an understanding what it does…

Linux has a property called control groups (cgrops) where you can bundle up processes and give them certain limitations.
You can take the system processes and put them in a cgroup with unlimited access to the CPU and take your user processes and put them in a cgroup with a very limited access to the CPU.
For instance.

Apparently the runtime_us knob is related to the cgroup limitations somehow and by entering -1 into it you switched it off.
That sysctl command is equivalent to sudo echo -1 > /proc/sys/kernel/sched_rt_runtime_us

Note that the sysctl command only affects the current session. As soon as you reboot you’ll get the original value.
It would, by the way, be interesting seeing what that value is.
Please run cat /proc/sys/kernel/sched_rt_runtime_us after your next reboot and post the result.
The default value in a live Xubuntu 20.04 session is 950000.

To make your setting permanent you have to edit /etc/sysctl.conf or add a file in /etc/sysctl.d and add the line kernel.sched_rt_runtime_us = -1

You can take the system processes and put them in a cgroup with unlimited access to the CPU and take your user processes and put them in a cgroup with a very limited access to the CPU.
For instance.

Thank you!

So, if I understand you correctly, less dumb solution is probably to create a cgroup for jackd with a needed amount of CPU resources (BTW, what value is needed)?

I’ve already read https://github.com/jackaudio/jackaudio.github.com/wiki/Cgroups, but there are no /etc/cgconfig.conf or /etc/cgrules.conf neither cgconfig service in my distribution.

Note that the sysctl command only affects the current session. As soon as you reboot you’ll get the original value.
It would, by the way, be interesting seeing what that value is.
Please run cat /proc/sys/kernel/sched_rt_runtime_us after your next reboot and post the result.
The default value in a live Xubuntu 20.04 session is 950000.

$ cat /proc/sys/kernel/sched_rt_runtime_us
950000

In AltLinux it has the same value.

I don’t have any experience with using cgroups so I really can’t say how it should be configured.
Ubuntu 20.04, and likely earlier versions too, has a cgroup-tools package which also contains example .conf files
AltLinux should have something similar.

If disabling runtime_us works it’s probably by far the easiest solution to the problem, even if it isn’t the most elegant one.

1 Like

I’ve upgraded and don’t have the issues.

I cannot use the LL-Kernel anymore after upgrading to 20.04. Display solution stucks at 640x480 and RT just gives me randomly XRUNS. For mixing its ok with the generic kernel, but it’s hard for recording and jamming.

TWIMC: I found the package with cgconfig service in my Linux distribution and the second solution from https://github.com/jackaudio/jackaudio.github.com/wiki/Cgroups (with group rtaudio) solved the problem after

sudo systemctl enable cgred
sudo systemctl enable cgconfig
systemctl reboot

I enabled RT features of the scheduler for all processes launched by user from group audio:

$ cat /etc/cgrules.conf
@audio   cpu    rtaudio/

Now JACK works even without -1 in /proc/sys/kernel/sched_rt_runtime_us.

The cause of problem was a kernel option CONFIG_RT_GROUP_SCHED. It disables RT-features without access configured through cgroups:
https://www.kernel.org/doc/Documentation/scheduler/sched-rt-group.txt
(this is explained in JACK wiki on the page linked above).

You can check this option in your kernel with the following command:

sudo cat /boot/config-`uname -r` | grep CONFIG_RT_GROUP_SCHED

On problematic kernels you’ll get

CONFIG_RT_GROUP_SCHED=y

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