Comment 2 for bug 1201180

I did some investigation last night. Here's what I found out. gnome-session doesn't (successfully) set a shutdown inhibitor lock, meaning that logind shuts the system down as soon as it is asked to. When run, gnome-session outputs the following warning

  gnome-session[6124]: WARNING: Error getting login monitor: -2

That comes from the following block of code

        if ((ret = sd_login_monitor_new (NULL, &sd_source->monitor)) < 0) {
                g_warning ("Error getting login monitor: %d", ret);
        } else {
                sd_source->pollfd.fd = sd_login_monitor_get_fd (sd_source->monitor);
                sd_source->pollfd.events = G_IO_IN;
                g_source_add_poll (source, &sd_source->pollfd);
        }

The return code there is '-2' which corresponds to ENOENT.

Checking the code for sd_login_monitor_new() in systemd shows that this function tries to inotify_add_watch() on a number of paths systemd cares about. If we strace -f -e trace=inotify_add_watch gnome-session then the output shows

  [pid 5439] inotify_add_watch(14, "/sys/fs/cgroup/systemd/machine", IN_MOVED_TO|IN_CREATE|IN_DELETE) = -1 ENOENT (No such file or directory)

And indeed this directory has not been created. In systemd:src/core/cgroup.c, these hierarchies are created here:

        if (m->running_as == SYSTEMD_SYSTEM) {
                cg_create(SYSTEMD_CGROUP_CONTROLLER, m->cgroup_hierarchy, "../user");
                cg_create(SYSTEMD_CGROUP_CONTROLLER, m->cgroup_hierarchy, "../machine");
        }

I believe the if check there is essentially systemd as PID 1, i.e. not true for Ubuntu.

In systemd git this seems to have moved to /run/systemd/machines/ created by systemd-machined.

Now, I'm not totally sure that this broken call is why the inhibitor lock isn't being set, but sd_login_monitor_new() definitely shouldn't be broken anyway and fixing this seems like a good place to start.