I'm running on a kernel with CONFIG_RT_GROUP_SCHED=y. I understand that
this is counter to the recommendation in the README ("We recommend to turn
off Real-Time group scheduling in the kernel when using systemd...."), but
I don't have control over the kernel configuration.
On this system, it appears that starting "docker" (docker-ce-17.06.0.ce-1)
results in the creation of new cpu cgroups that for some reason apply to
systemd services. That is, after starting docker,
/sys/fs/cgroup/cpu/system.slice exists when previously it didn't.
Once this happens, a service that attempts to set realtime scheduling
(SCHED_RR) via sched_setscheduler() will fail, presumably because the
cgroup has no realtime budget in cpu.rt_runtime_us.
In older versions of systemd one could handle this using the directives
described in
https://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/,
but unfortunately that document, despite being the number 1 search result
for pretty much anything involving "systemd" and "realtime", is obsolete
and those directives no longer exist.
Is there a way to make this work correctly with modern versions of
systemd? I've hacked around it for now by creating
/etc/systemd/system/myservice.service.d/realtime.conf that moves the
service back to the root cgroup and then uses chrt to set the scheduling
policy:
[Service]
ExecStartPost=/bin/cgclassify -g cpu:/ $MAINPID
ExecStartPost=/bin/chrt -r -p 99 $MAINPID
...and while that works, it seems really ugly. I've attempted to set
CPUSchedulingPolicy=rr in the unit, but that simply results in systemd
failing to start the service and logging "Failed at step SETSCHEDULER
spawning...".
Is there a better way of addressing this?
--
Lars Kellogg-Stedman <l...@redhat.com>
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
