<div dir="auto"><div>Some deployments that switch back their modern v2 host to hybrid or v1, are the ones that need to run old workloads that contain old systemd. Said old systemd only has experimental incomplete v2 support that doesn't work with v2-only (the one before current stable magick mount value).</div><div dir="auto"><br></div><div dir="auto">Specifically that is trying to run sustemd v229 in a container:</div><div dir="auto"><br></div><div dir="auto"><a href="https://bugs.launchpad.net/ubuntu/xenial/+source/systemd/+bug/1962332">https://bugs.launchpad.net/ubuntu/xenial/+source/systemd/+bug/1962332</a></div><div dir="auto"><br></div><div dir="auto">When cgroupsv2 got added in the kernel doesn't matter, as much as, when systemd started to correctly support cgroupsv2. <a href="https://github.com/systemd/systemd/commit/099619957a0/">https://github.com/systemd/systemd/commit/099619957a0/</a></div><div dir="auto"><br></div><div dir="auto">This shipped in v230 in May 2016, and I failed to backport this to v229 and make it work in a container on an otherwise v2-only host - it still failed to start for me.</div><div dir="auto"><br></div><div dir="auto">230 was one month too late, and hence v229 shipped in Xenial Ubuntu 16.04 LTS, which will be supported through to 2026, including as a container on newer hosts. Which for now only works if host is in hybrid or v1 modes.</div><div dir="auto"><br></div><div dir="auto">To me, 6 years support is too short for the case of old container on a new host.</div><div dir="auto"><br></div><div dir="auto">And I wish to resolve inability for v229 to start as a container on v2-only host and open to ship any minimal backport fix to unblock this.</div><div dir="auto"><br></div><div dir="auto">The inverse problem of running newer containers on older systems also exists, but usually such deployments find a way to also get newer hosts easily.</div><div dir="auto"><br></div><div dir="auto">Has anyone else managed to run v229 in a container on a v2-only host?</div><div dir="auto"><br></div><div dir="auto"><br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, 21 Jul 2022, 10:04 Lennart Poettering, <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Heya!<br>
<br>
It's currently a terrible mess having to support both cgroupsv1 and<br>
cgroupsv2 in our codebase.<br>
<br>
cgroupsv2 first entered the kernel in 2014, i.e. *eight* years ago<br>
(kernel 3.16). We soon intend to raise the baseline for systemd to<br>
kernel 4.3 (because we want to be able to rely on the existance of<br>
ambient capabilities), but that also means, that all kernels we intend<br>
to support have a well-enough working cgroupv2 implementation.<br>
<br>
hence, i'd love to drop the cgroupv1 support from our tree entirely,<br>
and simplify and modernize our codebase to go cgroupv2-only. Before we<br>
do that I'd like to seek feedback on this though, given this is not<br>
purely a thing between the kernel and systemd — this does leak into<br>
some userspace, that operates on cgroups directly.<br>
<br>
Specifically, legacy container infra (i.e. docker/moby) for the<br>
longest time was cgroupsv1-only. But as I understand it has since been<br>
updated, to cgroupsv2 too.<br>
<br>
Hence my question: is there a strong community of people who insist on<br>
using newest systemd while using legacy container infra? Anyone else<br>
has a good reason to stick with cgroupsv1 but really wants newest<br>
systemd?<br>
<br>
The time where we'll drop cgroupv1 support *will* come eventually<br>
either way, but what's still up for discussion is to determine<br>
precisely when. hence, please let us know!<br>
<br>
Thanks,<br>
<br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Berlin<br>
</blockquote></div></div></div>