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

[Lennart Poettering]

On Di, 06.08.19 08:58, TARANA, YASHASHVI (yashashvi.tarana at hpe.com) wrote:

> Hi Lennart,
>
> Thank you for getting back. I just subscribed to the systemd-devel mailing list and hence I'm resending the mail.
>
> We were following below article to get around the situation where a process fails to get realtime priority on a system once the CPUAccounting is enabled.
> https://access.redhat.com/articles/3696121
>
> It suggests to create your own slice and use it for your service.
>
> We would like to handle a situation where there are 2 such slices (A.slice & B.slice, created by different applications) on the system.
>
> Sample: test.service
> 	[Service]
> 	ExecStart=/root/test start
> 	ExecStop=/root/test stop
> 	Type=oneshot
> 	RemainAfterExit=yes
>
> Here, the binary at ExecStart (test) requires realtime priority.
>
> Scenario 1:
> ---------------
> Steps to Reproduce: 1. Suppose I have 2 slices, A.slice
> (cpu.rt_runtime_us value = 950000) and B.slice (cpu.rt_runtime_us
> value = 0) 2. Currently the service test.service is attached to
> A.slice 3. Now I changed cpu.rt_runtime_us values for these slices:
> A.slice to 0 and B.slice to 950000 (The values of A.slice and
> B.slice have been exchanged) 4. When I stop and start the service,
> binary at ExecStart determines that B.slice is the eligible slice
> and it updates the slice name in the configuration files and in
> drop-ins.  5. Updated slice information not reflected when start the
> binary and the start fails to set "realtime" priority.  6. Restart
> of the same service again works fine and attaches to correct slice
> (B.slice).

systemd does not support moving services between slices while they are
started. Currently, the cgroup is determined when the service is
started and then says unmodified until the service goes down.

(The kernel doesn't really support migrating processes between cgroups
that well either, the various counters do not fully get updated as one
might expect. The idea is generally that you change cgroup attributes
dynamically, and do not change cgroups/process membership after
initialization.)

> To work around the above problem in scenario 1 , I followed the below steps after step 3 above.
>
> 4. When I stop and start service again, the binary at Execstart determines the right slice( in this case, B.slice) and pushes its pid to B.slice tasks file(/sys/fs/cgroup/cpu,cpuacct/B.slice/tasks) in addition to updating the drop-ins.
> 5. The test service start successfully now but systemctl status
> test.service still shows that test.service is attached to the old
> slice (A.slice), although its pid is part of B.slice now.

Do not write directly to the "tasks" file. If systemd is your PID 1
then it owns the tree of all controllers it manages, and that includes
process membership. It's only OK to manage your own cgroup tree and
process membership therein if you registered a delegated subtree.

https://systemd.io/CGROUP_DELEGATION.html#delegation

But if you alter the process membership in the cgroups systems itself
manages you are basically on your own, it's simply not supported.

Lennart

--
Lennart Poettering, Berlin