Unity8 fails to start applications, cgmanager is not started under systemd

unity8/qtmir relies on ubuntu-app-launch for all application management, so fix is for UAL to get systemd support

having ubuntu-launch-app using systemd is orthogonal to this issue, in the current config upstart is still used for the user session and working correctly, only the system init changed

I put yesterday's desktop-next-amd64 image on an USB stick and booted it on my thinkpad x230, but I don't get very far (bad video modes, I see the "welcome to your phone" wizard, but aside from being able to move the mouse cursor nothing works, it's just stuck there), so I can't test this directly.

However, under systemd cgmanager doesn't start by default. So if UAL tries to talk to it, it's worth trying "sudo systemctl start cgmanager" and seeing if that helps things? (Note that cgmanager and systemd both manage cgroups, so they could collide).

I got u-desktop-next to boot, and confirm that starting cgmanager fixes app startup.

Hi Martin,

you marked this as affecting cgmanager. Could you be more specific about what the bug in cgmanager is?

If it is just that you want cgmanager to start automatically under systemd, then we will have to do that in ubuntu-specific packaging. We cannot do that in the debian packaging.

Serge: Yes, that's what I meant. I'd prefer getting this fixed properly in UAL, but if we need cgmanager for that, we can start it for that.

If we can't start cgmanager automatically in Debian because it interacts badly with systemd's cgroup management, this would just as well apply to Ubuntu. So *if* we can run them side by side, we can auto-enable its systemd unit; if that's not possible, and systemd and cgmanager collide, let's close that task as invalid.

Thanks!

> If we can't start cgmanager automatically in Debian because it interacts
> badly with systemd's cgroup management, this would just as well apply
> to Ubuntu.

No, the reason we cannot enable it in debian is not because it'll
break systemd. It does run fine.

> So *if* we can run them side by side, we can auto-enable its
> systemd unit; if that's not possible, and systemd and cgmanager collide,

Perhaps unity8 can enable it?

> let's close that task as invalid.

Discussed on IRC again. cgmanager changes the systemd controller and thus interferes with systemd. Also, in Ubuntu (not upstream or in Debian), we have a systemd patch to put logind sessions into all cgroup controllers (not just the systemd one) for supporting LXC user containers, which would potentially collide with cgmanager again. So it seems we can't really run them side by side, and UAL needs to call either cgmanager's or systemd's API for cgroup creation.

We discussed that again via email. In summary:

 - UAL and systemd units are non-overlapping use cases, and will not collide at all in practical use cases.
 - By itself, systemd only handles the "systemd" controller, which cgmanager should always stay out of
 - systemd units may configure cpu/memory/blkio cgroups with things like CPUShares=; so in principle, the started service could then do a cgmanager call to change these after the fact, but there's nothing stopping it from also doing these changes in /sys/fs/cgroup/ directly. This isn't a security feature, but a robustness/resource control one.

So what needs to happen:

 1. Ensure cgmanager doesn't change the "systemd" controller. (Should not happen in practice, but an explicit check can't hurt)
 2. Ensure cgmanager doesn't change an existing cgroup setup at startup, only upon request (which should already be true)
 3. Start cgmanager via socket/bus activation or at boot.

Cgmanager does not make any changes to the name=systemd controller without being asked to.

After some discussion it became clear that cgmanager does need to support name=systemd. It cannot ignore them, otherwise nested unprivileged containers will become impossible in many cases. For instance if the host is vivid running systemd, and lxc does not create a name=systemd cgroup for (and owned by) the user, and systemd is running in the container, then systemd in the container will not be able to control the name=systemd hierarchy in its own namespace.

cgmanger 0.35-1 will auto-enable cgmanager under systemd. (Note that it does not change the setting if cgmanager is being updated rather tha ninstalled). This should fix this bug. If you continue to have problems, please let us know.

(0.35-1 was uploaded to debian a shor ttime ago, should sync to vivid soon)

This bug was fixed in the package cgmanager - 0.35-1

---------------
cgmanager (0.35-1) unstable; urgency=medium

  * New upstream release.
  * debian/rules: drop --no-enable from systemd units. (LP: #1400394)

 -- Serge Hallyn <email address hidden> Mon, 12 Jan 2015 09:02:44 -0600