[systemd-devel] service fails to use the latest value of the slice

Lennart Poettering lennart at poettering.net
Thu Jul 25 17:14:51 UTC 2019


On Do, 25.07.19 13:02, Tiwari, Hari Sahaya (hari-sahaya.tiwari at hpe.com) wrote:

> Hello,
> I have one query on the behaviour I am overserving with systemd service.
>
> Below are the contents of service file,
>
> # cat /usr/lib/systemd/system/qs.service
> [Unit]
> Description=init script
> After=network.target
>
> [Service]
> ExecStartPre=/bin/sh /usr/local/cmcluster/bin/realtimeslice.sh -s /usr/lib/systemd/system/qs.service
> ExecStart=/usr/local/qs/bin/qs
> Type=simple
>
> [Install]
> WantedBy=multi-user.target
>
> What realtimeslice.sh does is to identify a slice having RT quantum
> (cpu.rt_runtime_us) as 950000.  Once the slice is identified the
> service attaches the binary mentioned in ExecStart to that slice.
> This is done because binary(/usr/local/qs/bin/qs) tries to set
> realtime priority.

I have trouble understanding this. I think there's some misconception
about what's systemd's slice concept is about.

Also note: systemd owns the cgroup tree. If you make changes to the
cgroup tree you are on your own, you are not supposed to, except if
you asked four own delegated subtree.

This means: attaching a process systemd manages for you to a different
cgroup with your own code is not supported, you are on your own.

That said, you can let systemd create cgroups and then adjust the
attributes that systemd doesn't manager yourself, such as the RT
attributes. For that use an ExecStartPre= that just sets these
attributes, and maybe make sure With CPUWeight=100 that you actually
get properly added to the "cpu" hierarchy...

Lennart

--
Lennart Poettering, Berlin


More information about the systemd-devel mailing list