Quoting Wolfgang Bumiller (w.bumil...@proxmox.com): > With systemd version 226 systemd apparently runs in a different cgroup > (init.scope) which causes problems: > https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1497420 > https://bugzilla.proxmox.com/show_bug.cgi?id=755 > > Apparently it keeps trying to restart systemd-journald, which is > accompanied by very informative log messages: > > Oct 12 08:49:36 myhost lxcfs[16970]: get_next_cgroup_dir: I was fed bad input > (repeated a bunch of times) > > I put the foreground lxc-start output at the bottom. > Since this is such a very informative error message I changed it a bit > to print the two strings it's comparing: > taskcg = lxc/103/init.scope > querycg = lxc/103/system.slice/systemd-journald.service > > Now, this 'init.scope' seems to be new in systemd. I'm not quite sure > if this is all there's to it, but since that was the first thing I saw > it's what I went with, and I'm having some questions regarding my > understanding of the lxcfs code regarding caller_is_in_ancestor() and > get_next_cgroup_dir(). > > For one, it seems overly restrictive - more than a usual system would > be if I'm not mistaken?
It's not overly restrictive. See https://github.com/lxc/cgmanager/blob/master/README for the full rationale The new unified hierarchy restriction of no tasks in non-leaf nodes is unfortunate... cgmanager deals with it by quietly placing tasks in a .cgm_leaf child of the requested cgroup (in compatibility mode). Note that the no-tasks-in-non-leaf-nodes rule does *not apply to the root cgroup. But that doesn't help with containers. I'll probably end up adding an exception for 'init.scope' to allow escaping to the parent in that case. _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
