<div dir="ltr"><div dir="ltr">> What's stopping you from mounting a private "named" cgroup v1</div>> hierarchy to such containers (i.e. no controllers). systemd will then<br>> use that when taking over and not bother with mounting anything on its<br>> own, such as a cgroupv2 tree.<div><br></div><div>We specifically want to be able to make use of cgroup controllers within the container. One example of this would be to use "MemoryLimit" (cgroupv1) for a systemd unit (I understand this is deprecated in the latest versions of systemd, but as far as I can see we wouldn't be able to use the cgroupv2 "MemoryMax" config in this scenario anyway).</div><div><br></div><div>> You are doing something half broken and</div>> outside of the intended model already, I am not sure we need to go the<br>> extra mile to support this for longer.<div><br></div><div>I'm slightly surprised and disheartened by this viewpoint. I have paid close attention to <a href="https://systemd.io/CONTAINER_INTERFACE/">https://systemd.io/CONTAINER_INTERFACE/</a> and <a href="https://systemd.io/CGROUP_DELEGATION/">https://systemd.io/CGROUP_DELEGATION/</a>, and I'd interpreted the statement as being that running systemd in a container should be fully supported (not only on cgroupsv2, at least using recent-but-not-latest systemd versions).</div><div><br></div><div>In particular, the following:</div><div><br></div><div>"Note that it is our intention to make systemd systems work flawlessly and
out-of-the-box in containers. In fact, we are interested to ensure that the same
OS image can be booted on a bare system, in a VM and in a container, and behave
correctly each time. If you notice that some component in systemd does not work
in a container as it should, even though the container manager implements
everything documented above, please contact us."<br></div><div><br></div><div>"When systemd runs as container payload it will make use of all hierarchies it
has write access to. For legacy mode you need to make at least
<code class="gmail-language-plaintext gmail-highlighter-rouge">/sys/fs/cgroup/systemd/</code> available, all other hierarchies are optional."</div><div><br></div><div>I note that point 6 under "Some Don'ts" does correlate with what you're saying:</div><div>"Think twice before delegating cgroup v1 controllers to less privileged
containers. It’s not safe, you basically allow your containers to freeze the
system with that and worse."</div><div>However, in our case we're talking about a privileged container, so this doesn't really apply.</div><div><br></div><div>I think there's a definite use-case here, and unfortunately when systemd drops support for cgroupsv1 I think this will just mean we'll be unable to upgrade the container's systemd version until all relevant hosts use cgroupsv2 by default (probably a couple of years away).</div><div><br></div><div>Thanks for your time,</div><div>Lewis</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 7 Aug 2023 at 17:26, Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Do, 20.07.23 01:59, Dimitri John Ledkov (<a href="mailto:dimitri.ledkov@canonical.com" target="_blank">dimitri.ledkov@canonical.com</a>) wrote:<br>
<br>
> Some deployments that switch back their modern v2 host to hybrid or v1, are<br>
> the ones that need to run old workloads that contain old systemd. Said old<br>
> systemd only has experimental incomplete v2 support that doesn't work with<br>
> v2-only (the one before current stable magick mount value).<br>
<br>
What's stopping you from mounting a private "named" cgroup v1<br>
hierarchy to such containers (i.e. no controllers). systemd will then<br>
use that when taking over and not bother with mounting anything on its<br>
own, such as a cgroupv2 tree.<br>
<br>
that should be enough to make old systemd happy.<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div></div></div>