Bug 87570

Summary: Real time priority broken with systemd 218
Product: systemd Reporter: Adriano Moura <adriano.lols>
Component: generalAssignee: systemd-bugs
Status: RESOLVED WONTFIX QA Contact: systemd-bugs
Severity: normal    
Priority: medium CC: martin, patrakov, triode1, zdzichu
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:

Description Adriano Moura 2014-12-22 00:03:03 UTC
Can't elevate process scheduling from normal to real time (fifo), neither as a normal user or root. It's a fully updated archlinux system with the just released systemd 218.

Steps to reproduce:
Look for this rtkit-daemon log output, when it starts:
rtkit-daemon[10832]: Successfully called chroot.
rtkit-daemon[10832]: Successfully dropped privileges.
rtkit-daemon[10832]: Successfully limited resources.
rtkit-daemon[10832]: Running.
rtkit-daemon[10832]: Canary thread running.
rtkit-daemon[10832]: Failed to make ourselves RT: Operation not permitted
rtkit-daemon[10832]: Watchdog thread running.

downgrade to systemd 217
notice that rtkit-daemon does not outputs "Failed to make ourselves RT: Operation not permitted" anymore and any process that request real time scheduling (like jack) will now work properly.
Comment 1 triode1 2015-01-25 00:06:40 UTC
I see the same problem on arch linux arm.

Strangely if a unit is created early enough at boot time, I can get real time priority, but if it is restarted then it gets assigned to system.slice and can't get it.

Can a mechanism to always force use the root slice for cpu please be returned?
Comment 2 Harvey 2015-07-10 09:22:20 UTC
Still to be seen on archlinux x86-64 with systemd 222
Comment 3 Lennart Poettering 2015-07-11 17:48:59 UTC
Please turn off RT group scheduling in your kernel. 

For background, please see:

https://bugzilla.redhat.com/show_bug.cgi?id=1229700

and:

https://github.com/systemd/systemd/pull/553

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.