On Tue, Oct 25, 2022 at 02:49:35PM +0200, Pavel Hrdina <phrdina@redhat.com> wrote:
Exactly, there is the same ordering issue, if cgroup v2 backend is enabled it is the only one used for cpuacct and devices within libvirt code.
Aha, I see what's the issue with the approach now.
BTW do you have any pointers (a commit) when the hybrid mode could have become broken for libvirt/lxc? (I estimate from the (lack of) user reports that it must have worked at the time of libvirt 4.0.)
Only this specific hybrid mode of systemd which is cgroup v1 for everything and unified for process tracking.
I mean we've had the hybrid mode since Leap 15.0 and apparently there were no (reported) issues of this kind (libvirt/lxc) until Leap 15.3 (which roughly translates to libvirt >= 7.1.0). So it must have worked somehow and something changed meanwhile (move to use the systemd API partially to manage cgroups?).
As I've already mentioned in previous reply, to fix the process tracking we should ideally use
org.freedesktop.systemd1.Manager.AttachProcessesToUnit
dbus call to add the process into the cgroup
This is a rather low-level (and as you mentioned internal purposes) API. It should primarily use org.freedesktop.machine1.Manager.CreateMachine() or org.freedesktop.systemd1.Manager.StartTransientUnit() if machined is unwanted. These calls would ensure that processes are migrated in all hierarchies there are (i.e. v2 and all v1s in hybrid mode) by systemd. I thought that recent libvirt (8.7.0 manifests the bug on hybrid too) would only use the systemd API. Do I get it correctly that it only applies to the libvirt "core" and then libvirt/lxc needs to place some more processes together with the leader process? (Which currently works only with full v1 or full v2 mode by direct cgroupfs manipulation.) Thanks, Michal