← Back to team overview

touch-packages team mailing list archive

Re: [Bug 1413927] Re: user lxc containers fail to start under systemd: login name=systemd cgroup is not owned by user

 

Quoting Martin Pitt (martin.pitt@xxxxxxxxxx):
> Stéphane Graber [2015-01-25 17:15 -0000]:
> > How are we supposed to run a systemd container on such a system then?
> > 
> > systemd in a container will need to create sub-entries in the
> > name=systemd controller.
> 
> Yes, that works fine, as the cgroup *directories* are owned by the
> user. I just don't want to make the cgroup.procs and task files owned
> by the user, as that would allow the user to modify that "session
> root" cgroup and move PIDs between host sessions. What user containers
> do in sub-groups of the host's "session-XX.cgroup" is up to them, and
> of course the user on the host can meddle with them from the outside.

If that's all you're objecting to, we can make do with that.  The
important things are that (a) the directory be owned by the user
and (b) all files other than tasks and cgroup.procs files NOT be
owned by the user :)  Having the tasks file owned by the uesr is
only a nicety.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1413927

Title:
  user lxc containers fail to start under systemd: login name=systemd
  cgroup is not owned by user

Status in systemd package in Ubuntu:
  Fix Committed

Bug description:
  When a user logs in, systemd-logind should create cgroups for the
  user, with the directory (i.e.
  /user.slice/user-1000.slice/session-c2.scope) owned by the user.  This
  is no longer hapening for the name=systemd cgroup.  This prevents
  containers from starting.  (If lxc were to simply not create/use that
  controller, then it would prevent system in the container from using
  it).

  I wanted to test the new lxc with lxcfs. A system container (with
  upstart or systemd) works perfectly well now (great!), but user
  containers regressed:

  $ lxc-create -n v1 -t download -- -d ubuntu -r vivid -a amd64
  $ lxc-start -n v1  -F
  lxc-start: cgmanager.c: lxc_cgmanager_enter: 694 call to cgmanager_move_pid_sync failed: invalid request
  lxc-start: start.c: __lxc_start: 1099 failed to spawn 'v1'
  lxc-start: lxc_start.c: main: 345 The container failed to start.

  My host is running systemd, but cgmanager is running (i. e. it's not
  bug 1400394, I enabled cgmanager.service).

  ProblemType: Bug
  DistroRelease: Ubuntu 15.04
  Package: lxc 1.1.0~rc1-0ubuntu1
  ProcVersionSignature: Ubuntu 3.18.0-9.10-generic 3.18.2
  Uname: Linux 3.18.0-9-generic x86_64
  ApportVersion: 2.15.1-0ubuntu2
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Fri Jan 23 10:35:55 2015
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2014-11-20 (63 days ago)
  InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Alpha amd64 (20141119)
  SourcePackage: lxc
  UpgradeStatus: No upgrade log present (probably fresh install)
  defaults.conf:
   lxc.network.type = veth
   lxc.network.link = lxcbr0
   lxc.network.flags = up
   lxc.network.hwaddr = 00:16:3e:xx:xx:xx
  lxc.conf: lxc.lxcpath = /srv/lxc

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1413927/+subscriptions


References