On Wed, 12.07.17 11:41, Lars Kellogg-Stedman (l...@redhat.com) wrote: > On Thu, Jul 6, 2017 at 10:56 AM, Lars Kellogg-Stedman <l...@redhat.com> > wrote: > > > 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: > > > > It looks like systemd sets up cgroups before calling ExecStartPre, which > means I can emulate the behavior of those obsolete directives by running: > > ExecStartPre=/bin/sh -c 'echo 550000 > > /sys/fs/cgroup/cpu,cpuacct/cpu.rt_runtime_us' > ExecStartPre=/bin/sh -c 'echo 200000 > > /sys/fs/cgroup/cpu,cpuacct/system.slice/cpu.rt_runtime_us' > ExecStartPre=/bin/sh -c 'echo 200000 > > /sys/fs/cgroup/cpu,cpuacct/system.slice/myservice.service/cpu.rt_runtime_us' > > In an environment where CONFIG_RT_GROUP_SCHED is set, is this the best way > of addressing the problem?
Yeah, this would probably work, but you should really set CPUAccounting=1 too, as an indirect way to ensure your unit appears in the "cpu"/"cpuacct" cgroup hierarchy in the first place. And I'd probably turn this into a proper shell script, that dynamically reads the path from /proc/self/cgroup and then propagates things up properly. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list firstname.lastname@example.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel