http://bugzilla.opensuse.org/show_bug.cgi?id=1183247 http://bugzilla.opensuse.org/show_bug.cgi?id=1183247#c34 --- Comment #34 from Eric van Blokland <ericvanblokland@gmail.com> --- (In reply to Michal Koutn� from comment #33)
(In reply to Eric van Blokland from comment #32)
To me it seems as if the control process is correctly added to the new scope. However, the PID remains tied to the old scope.
There are multiple hierarchies, for systemd tracking purposes the only v2 is relevant.
Like I said my understanding of cgroups is extremely limited. I have no clue about the differences between v1, v2 and what unified is supposed to mean. Somehow I was led to believe that v2 is unified.
I've tried changing the controller ...
Do you refer to libvirt or lxc or other code here?
I'm referring to the code in libvirt, specifically the code for the lxc controller process (lxc_controller) that attempts to associate the process with correct cgroups
... to use cgroup.procs instead of tasks, which does get rid of the process in the old scope.
(That should only cause change if you dealt with multi-threaded processes.)
So I understood and as far as I've seen the lxc_controller process is not threaded. Imagine my confusion. Could the controller be running threads to handle IPC?
However, the last line of /proc/PID/cgroup never changes and systemd does not find the controller process in the correct unit.
The last row (assuming it's the '0::' v2 hierarchy) is the "source of truth" for systemd when it comes to unit assocition (when it runs in hybrid or unified mode).
I glanced over the systemd code and that led me to believe that if it's not using unified cgroups, it uses the controller at 1:name=systemd Or does it use the "unified code path" when v2 is available? While I am writing this I think to recall only v1 was mounted, but now I'm unsure, I would have to check. Anyway, it is clear I'm having some issues with the terminology. -- You are receiving this mail because: You are on the CC list for the bug.