[systemd-devel] name=systemd cgroup mounts/hierarchy

[Michal Koutný]

Hi.

On Wed, Nov 18, 2020 at 09:46:03PM +0300, Andrei Enshin <b1os at bk.ru> wrote:
> Just out of curiosity, how systemd in particular may be disrupted with
> such record in root of it’s cgroups hierarchy as /kubpods/bla/bla
> during service (de)activation?
> Or how it may disrupt the kubelet or workload running by it?
If processes from kubeletet.service are migrated elsewhere, systemd may
lose ability to associate it with the service (which may or may not be
correct, I didn't check this particular case).

In the opposite direction, if container runtime builds up a hierarchy
for a controller, systemd isn't aware of it and it would clean the
hierarchy according to its configuration (which can, for instance, be no
controllers at all) and happens during unit (de)activation. The
containers can get away with it when there are no unit changes at the
moment but that's not what you want. Furthermore, since cgroup
operations for a unit usually involve family [1], the interference may
happen even when apparently unrelated unit changes. (This applies to the
most common "hybrid" cgroup layout.)

> Seems I missed some technical details how exact it will interfere.
There's the defined interface (delegation or DBus API) and both parties
(systemd, container runtimes) have freedom to implement cgroups as they
wish within these limits.
If they overlap though, you get an undefined behavior in principle.
That's the reason why to stick to this convention.

Michal


[1] This is rather an implementation detail 
    https://github.com/systemd/systemd/blob/f56a9cbf9c20cd798258d3db302d51bf21458b38/src/core/cgroup.c#L2326

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20201119/617b12fc/attachment-0001.sig>