On Tue, Oct 25, 2022 at 02:49:35PM +0200, Pavel Hrdina <phrdina@xxxxxxxxxx> 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
Attachment:
signature.asc
Description: Digital signature
