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.
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-session in Ubuntu.
https://bugs.launchpad.net/bugs/1201180
Title:
Pressing power button turns off the PC ignoring the presence of
another session manager
Status in “gnome-session” package in Ubuntu:
New
Status in “systemd” package in Ubuntu:
New
Status in “systemd-shim” package in Ubuntu:
Invalid
Bug description:
In saucy the PC powers down as soon as I press the power button, it
seems that systemd is calling "poweroff", but I'm not sure if it's
doing that in response of some other event (i.e. as callback of a dbus
call):
root 4998 0.0 0.0 177932 2104 ? Sl 20:41 0:00
/usr/lib/x86_64-linux-gnu/systemd-shim
root 5012 0.0 0.0 4440 624 ? S 20:41 0:00 \_ sh -c
/sbin/poweroff
root 5013 0.0 0.0 4440 628 ? S 20:41 0:00 \_
/bin/sh /sbin/shutdown -h -P now
In any case the caller or systemd itself should be aware that there's
a session-manager running and that it shouldn't actually directly
power off the system then.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1201180/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
