Comment # 34 on bug 1183247 from Eric van Blokland

(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.