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