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 Poettering, Red Hat
systemd-devel mailing list

Reply via email to