Bug 980692 - gdm login screen in VMs: the ACPI power button should by default effect a shutdown
Summary: gdm login screen in VMs: the ACPI power button should by default effect a shu...
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gnome-settings-daemon
Version: 7.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Rui Matos
QA Contact: Desktop QE
: 1040307 1163712 1231600 1242075 (view as bug list)
Depends On: 1028451
Blocks: 1187263
TreeView+ depends on / blocked
Reported: 2013-07-03 03:42 UTC by Sibiao Luo
Modified: 2017-07-03 15:05 UTC (History)
24 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2015-11-19 08:23:36 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:2157 0 normal SHIPPED_LIVE control-center bug fix and enhancement update 2015-11-19 08:48:59 UTC

Description Sibiao Luo 2013-07-03 03:42:00 UTC
Description of problem:
boot up a rhel guest but did not login guest, tried to do system_powerdown in HMP monitor to poweroff guest, but guest fail to poweroff.
This scenario is a little different to bug 907711 which has login to guest and its behavior like S3.
btw, if hit the 'Power off' button in the upper right corner of the guest, it can poweroff susccessfully.
I also tried the rhel6 guest in rhel6 host, it has no such issue, it can poweroff sccessfully.

Version-Release number of selected component (if applicable):
host info:
guest info:

How reproducible:

Steps to Reproduce:
1.boot up a rhel7 guest but did not login to guest.
# /usr/libexec/qemu-kvm -M q35 -cpu SandyBridge -enable-kvm -m 4096 -smp 4,sockets=2,cores=2,threads=1 -no-kvm-pit-reinjection -name sluo -uuid 355a2475-4e03-4cdd-bf7b-5d6a59edaa61 -rtc base=localtime,clock=host,driftfix=slew -device pci-bridge,bus=pcie.0,id=bridge1,chassis_nr=1,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0,bus=bridge1,addr=0x4 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port2 -drive file=/home/RHEL-7.0-20130628.0-Server-x86_64.qcow3,if=none,id=drive-system-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,serial="QEMU-DISK1" -device virtio-scsi-pci,num_queues=4,id=scsi0,bus=bridge1,addr=0x5 -device scsi-hd,bus=scsi0.0,drive=drive-system-disk,id=system-disk,bootindex=1 -device virtio-balloon-pci,id=ballooning,bus=bridge1,addr=0x6 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -netdev tap,id=hostnet0,vhost=on,queues=4,script=/etc/qemu-ifup -device virtio-net-pci,mq=on,vectors=17,netdev=hostnet0,id=virtio-net-pci0,mac=08:2e:5f:0a:0d:b1,bus=bridge1,addr=0x7,bootindex=2 -k en-us -boot menu=on -qmp tcp:0:4444,server,nowait -serial unix:/tmp/ttyS0,server,nowait -vnc :1 -spice port=5931,disable-ticketing -monitor stdio
2.do system_powerdown in HMP monitor.
(qemu) system_powerdown

Actual results:
after step 2, guest faill to poweroff after do system_powerdown, it has no any 	
response, and the guest dmesg output nothing.
(qemu) info status 
VM status: running
(qemu) system_powerdown 
(qemu) info status 
VM status: running

Expected results:
it can poweroff guest successfully.

Additional info:

Comment 1 Laszlo Ersek 2013-07-09 11:39:04 UTC
Yes I've experienced this (or something very similar) myself, for example clicking the Shut Down button in virt-manager's guest window doesn't seem to do anything.

When the "system_powerdown" HMP command is issued, qemu does the following [hmp-commands.hx]:

        powerdown_requested = 1

Then, in the main loop,


The powerdown notifier list is extended with qemu_register_powerdown_notifier(), one such caller is:


and the callback function is piix4_pm_powerdown_req(). Which does:

        (via funcptr) pm_update_sci()

which should ultimately raise the System Control Interrupt in the guest.

Comment 2 Laszlo Ersek 2013-07-09 13:29:45 UTC
I verified in a RHEL-6 guest (on a RHEL-7 host) that SCI is injected
correctly, IRQ 9 (named "acpi") in /proc/interrupts is bumped by one each
time I click the Shut Down button.

The same bump is visible in the RHEL-7 guest as well, but the RHEL-7 guest
even shuts down consequently. Seeing this, I repeated the test using the

# virsh qemu-monitor-command fw-seabios7.g-rhel7.e-rhel7 \
      --hmp system_powerdown

and indeed the RHEL-7 guest shut down again.

I think I'll have to explore this systematically, as the reports here and in
bug 907711 seem to be somewhat inconsistent.

Regarding q35 testing: since RHEL-7 libvirt doesn't seem to support q35 yet
(see eg. bug 819968), I must check it using the qemu-kvm command line:

  /usr/libexec/qemu-kvm \
    -M q35 \
    -S \
    -enable-kvm \
    -m 4096 \
    -monitor stdio \
    -vga cirrus \
    -netdev user,id=net0 \
    -device virtio-net-pci,netdev=net0 \
    -drive file=/var/lib/libvirt/images/clone.img,if=virtio,format=qcow2 \
    -no-kvm-pit-reinjection \
    -rtc base=localtime,clock=host,driftfix=slew \
    -smp 4 \
    -vnc :1

(I started with the command line in comment #0 and trimmed it down until it
was something usable.)

Host components:
- kernel: 3.10.0-0.rc7.64.el7
- qemu-kvm-1.5.0-2.el7
- seabios-bin:
- libvirt*: 1.0.6-1.el7
- poweroff attempt: via HMP command quoted above


  guest         | 3.10.0-0.rc7.64.el7 | 2.6.32-358.el6
  pc-q35-1.5    | works               | doesn't work (SCI delivered)
  pc-i440fx-1.5 | works               | doesn't work (SCI delivered)

In other words, I cannot reproduce the problem with a RHEL-7 guest. I don't
think this has anything to do with my command line being simpler than the
one in comment 0.

I can reproduce the problem with a RHEL-6.4 guest, and for that guest piix4
vs. q35 makes no difference.

Comment 3 Laszlo Ersek 2013-07-09 13:41:32 UTC
All four results identical with qemu-kvm-1.5.1-2.el7.x86_64.

Comment 4 Laszlo Ersek 2013-07-09 13:54:49 UTC
I installed "acpid" in the RHEL-6.4 guest, and "system_powerdown" started working immediately.

Sibiao, can you please test the following:
- in the guest, run "watch --interval=0.1 grep acpi /proc/interrupts"
- issue the "system_powerdown" monitor command,
- does that increment any of the counters for IRQ#9 (acpi)?

Also, what does "/etc/systemd/logind.conf" say for "HandlePowerKey" in the guest? See <https://wiki.archlinux.org/index.php/Systemd#ACPI_power_management>.


Comment 6 Laszlo Ersek 2013-07-10 06:40:20 UTC
Thank you for the info. One further question:

> There was a old rhel7 image(kernel-3.7.0-0.36.el7.x86_64) on my host, and
> i tried it with the same steps as comment #0 which did not hit this issue,
> it can do system_powerdown var HMP monitor successfully and the guest can
> be shutdown correctly.

In this test case, did you replace the fresh (RHEL-7.0-20130628.0) image with the old (kernel-3.7.0-0.36.el7) in the host, or in the guest?

- your host components (qemu seabios kernel libvirt etc) were unchanged,
- an older RHEL-7 guest image worked correctly,
- and the fresh RHEL-7 guest image doesn't work, *but* the SCI is injected each time,

then this could be a systemd (... or guest kernel configuration?) regression.

Comment 7 Laszlo Ersek 2013-07-10 06:49:14 UTC
bug 927609 could be related

Comment 8 Laszlo Ersek 2013-07-10 07:17:45 UTC

right after you issue the "system_powerdown" command (and nothing happens except the interrupt counter going up), can you please run

  journalctl --since=today >journal.txt

and upload that file here?

Because, in the guest,

  journalctl --since=today | egrep -i 'power (button|key)'

should produce lines such as:

  1  kernel: input: Power Button as
  2  kernel: ACPI: Power Button [PWRF]
  3  systemd-logind[455]: Watching system buttons on
                         /dev/input/event0 (Power Button)
  4  systemd-logind[455]: Power key pressed.

Line 1 to line 3 are produced during VM boot and systemd startup.

Line 4 should be produced in response to the "system_powerdown" command. Also, looking at the unfiltered output of

  journalctl --since=today

the message

  systemd-logind[455]: Power key pressed.

should be directly followed by

  systemd-logind[455]: Powering Off...
  systemd-logind[455]: System is powering down.

"journal.txt" might allow me more insight to what's happening (and possibly reassign to systemd).


Comment 12 Laszlo Ersek 2013-07-10 11:57:24 UTC
Not sure if this is a duplicate of bug 927609, but very closely related.

I installed @gnome-desktop in my RHEL-7 guest, pointed to
"/etc/systemd/system/default.target" symlink at
"/lib/systemd/system/graphical.target", and rebooted.

Indeed the Shut Down button of the virt-manager window has stopped working,
and so has the

  virsh qemu-monitor-command fw-seabios7.g-rhel7.e-rhel7 \
      --hmp system_powerdown

host-side command.

These are the relevant startup messages from the journal (journalctl

  systemd-logind[461]: New session c1 of user gdm.

  systemd[1]: Starting Daemon for power management...
  dbus-daemon[467]: dbus[467]: [system] Successfully activated service
  dbus[467]: [system] Successfully activated service
  systemd[1]: Started Daemon for power management.

Then, this is all that happens in response to the Shut Down button in

  systemd-logind[461]: Power key pressed.

No subsequent

  systemd-logind[455]: Powering Off...
  systemd-logind[455]: System is powering down.

messages; clearly HandlePowerKey has been inhibited.

  # loginctl

   SESSION        UID USER             SEAT
        c1         42 gdm              seat0
         3          0 root

(Note that session 3 was not active when I tried to power off the VM, I
logged in over SSH only to run loginctl.)

  # loginctl session-status c1

  c1 - gdm (42)
             Since: Wed 2013-07-10 12:02:48 CEST; 10min ago
            Leader: 587 (gdm-session-wor)
              Seat: seat0; vc1
           Display: :0
           Service: gdm-launch-environment; type x11; class greeter
             State: active
            CGroup: systemd:/user/42.user/c1.session
                    |- 587 gdm-session-worker [pam/gdm-launch-environment]
                    |- 790 /usr/bin/gnome-session \
                    |      --autostart /usr/share/gdm/greeter/autostart
                    |- 805 /usr/bin/dbus-launch \
                    |      --exit-with-session /usr/bin/gnome-session \
                    |      --autostart /usr/share/gdm/greeter/autostart
                    |- 940 /bin/dbus-daemon --fork --print-pid 4 \
                    |      --print-address 6 --session
                    |- 944 /usr/libexec/at-spi-bus-launcher
                    |- 948 /bin/dbus-daemon \
                           --config-file=/etc/at-spi2/accessibility.conf \
                           --nofork --print-address 3
                    |- 952 /usr/libexec/at-spi2-registryd \
                    |- 962 /usr/libexec/gnome-settings-daemon
                    |-1018 gnome-shell --mode=gdm
                    |-1026 /usr/bin/pulseaudio --start --log-target=syslog
                    `-1049 /usr/libexec/dconf-service

The "upower" daemon <http://upower.freedesktop.org/docs/>, version
upower-0.9.20-1.el7, is running:

  # systemctl status upower

  upower.service - Daemon for power management
     Loaded: loaded (/usr/lib/systemd/system/upower.service; disabled)
     Active: active (running) since Wed 2013-07-10 12:02:51 CEST; 14min ago
       Docs: man:upowerd(8)
   Main PID: 971 (upowerd)
     CGroup: name=systemd:/system/upower.service
             `-971 /usr/libexec/upowerd

  Jul 10 12:02:51 localhost.localdomain systemd[1]: Started Daemon for power

However the Loaded line says it is "disabled". Indeed, running "upower
--monitor-detail" and clicking the Shut Down button again, prints nothing.

This is a GNOME configuration bug.

If I actually log in to the GUI in the guest, then the Shut Down button
starts working, but it only suspends the virtual machine, instead of
shutting it down. This originates form the following gnome configuration

  # gsettings get org.gnome.settings-daemon.plugins.power button-power

  # gsettings list-recursively org.gnome.settings-daemon.plugins.power
  org.gnome.settings-daemon.plugins.power button-hibernate 'hibernate'
  org.gnome.settings-daemon.plugins.power button-power 'suspend'
  org.gnome.settings-daemon.plugins.power button-sleep 'hibernate'
  org.gnome.settings-daemon.plugins.power button-suspend 'suspend'


- I cannot change the value from a root shell:
  # gsettings set org.gnome.settings-daemon.plugins.power button-power shutdown

  (process:1381): dconf-WARNING **: failed to commit changes to dconf: Error
  spawning command line `dbus-launch
  --autolaunch=4734061f583b1094ba6d2e38e9a124dd --binary-syntax
  --close-stderr': Child process exited with code 1

- When no user is logged in via gdm, then not even suspend works. It simply
  does nothing.
- I tried to change the system-wide default, following the instructions in
  (a) created the file "/etc/dconf/db/gdm.d/01-poweroff" with the following

  (b) ran "dconf update"
  (c) rebooted the guest
  (d) no change in behavior

... I installed "dconf-editor" and ran it in the GUI session. I navigated
to  org/gnome/settings-daemon/plugins/power, and set "button-power" to
"shutdown". Then clicking virt-manager's Shut Down button pulls up a dialog,
asking/warning the user about powering off in 60 seconds.

If in addition I set "logout-prompt" to "false", under
org/gnome/SessionManager, then virt-manager's Shut Down button finally does
what it should, but again, only when a user is logged in via GDM. On the GDM
login screen, nothing happens.

I'm moving this BZ over to gdm.

Comment 13 Laszlo Ersek 2013-07-10 14:18:41 UTC
This could be an upstream bug.

Some references:
- https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=6defe42c
- https://bugzilla.gnome.org/show_bug.cgi?id=680689

gsd_media_keys_manager_init() [/plugins/media-keys/gsd-media-keys-manager.c] inhibits "handle-power-key" in systemd via a dbus message. This is in effect as soon as the GDM greetings / user selector screen shows up. In the guest:

  # systemd-inhibit --list

     Who: gdm (UID 42/gdm, PID 962/gnome-settings-)
    What: handle-power-key:handle-suspend-key:handle-hibernate-key
     Why: GNOME handling keypresses
    Mode: block


I can't figure out why the ACPI power button is handled when a user is logged in vs. not handled at all on the greeter screen. GSD_POWER_ACTION_SHUTDOWN sends a Shutdown message to gnome-session (the session manager) over D-Bus, implemented in <https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=f268b2d2>, by calling gnome_session_shutdown().

Well, I do have an idea; and it doesn't look good. Get gnome-session from <https://git.gnome.org/browse/gnome-session>, and change to the "gnome-session" directory in the clone.

The README file explains the startup phases of gnome session manager. The phase names are actually incorrect, the phases must have been renamed slightly with time. In any case, the enum constants are in "gsm-manager.h":

typedef enum {
        /* gsm's own startup/initialization phase */
        /* xrandr setup, gnome-settings-daemon, etc */
        /* window/compositing managers */
        /* apps that will create _NET_WM_WINDOW_TYPE_PANEL windows */
        /* apps that will create _NET_WM_WINDOW_TYPE_DESKTOP windows */
        /* everything else */
        /* done launching */
        /* shutting down */
} GsmManagerPhase;

Now let's see how gnome-session handles the Shutdown message: 

gsm_manager_shutdown (GsmManager *manager,
                      GError    **error)
    gboolean shell_running;

    g_debug ("GsmManager: Shutdown called");

    g_return_val_if_fail (GSM_IS_MANAGER (manager), FALSE);

    if (manager->priv->phase != GSM_MANAGER_PHASE_RUNNING) {
        g_set_error (error,
            "Shutdown interface is only available during the Running phase");
        return FALSE;

When no user is logged in, the gnome session manager is in a phase that differs from RUNNING. If gnome-settings-daemon sends the Shutdown message over D-Bus at this point, in response to the ACPI power button, then gnome-session simply rejects the message.

gnome-session commit 577746e1 is instrumental; originally this used to be called "Logout interface". Clearly logout doesn't make sence if we're not yet logged in, poweroff does though.

Comment 14 Matthias Clasen 2013-11-06 10:57:54 UTC
> When no user is logged in, the gnome session manager is in a phase that
> differs from RUNNING. If gnome-settings-daemon sends the Shutdown message
> over D-Bus at this point, in response to the ACPI power button, then
> gnome-session simply rejects the message.

No, that is not true. We run a separate session for the login screen, and the gnome-session running it *is* in the running phase. The process actually handling the power key is gnome-settings-daemon, in the media-keys plugin.

Comment 15 Matthias Clasen 2013-11-06 11:51:00 UTC
I assume this is a complaint about the default value of the
org.gnome.settings-daemon.plugins.power button-power
key, which is 'suspend'

To test this theory, does the following help ?

cat >/etc/dconf/db/gdm.d/01-power <<EOF
dconf update

(not 100% sure if the symbolic enum value for button-power works there, please try an explicit


as well

Comment 16 Bastien Nocera 2013-11-06 12:15:53 UTC
If the request is for the power button to shutdown, it should be as easy as modifying gdm's GSettings in /etc/dconf/db/gdm.d/00-upstream-settings.

Was that it?

Comment 17 Laszlo Ersek 2013-11-06 13:31:42 UTC
(In reply to Matthias Clasen from comment #15)
> I assume this is a complaint about the default value of the
> org.gnome.settings-daemon.plugins.power button-power
> key, which is 'suspend'
> To test this theory, does the following help ?
> cat >/etc/dconf/db/gdm.d/01-power <<EOF
> [org/gnome/settings-daemon/plugins/power]
> button-power=shutdown
> dconf update

I already tried this in comment 12 (search for the string "org/gnome/settings-daemon/plugins/power"), and it didn't work.

I tried again, and it doesn't work now either.

BTW single quotes are needed around the word "shutdown", otherwise the "dconf update" command fails with:

  /etc/dconf/db/gdm.d/01-poweroff: [org/gnome/settings-daemon/plugins/power]:
  button-power: skipping invalid value: shutdown (0-8:unknown keyword)

But, again, even if the quoting is correct, the setting has no effect.

> (not 100% sure if the symbolic enum value for button-power works there,
> please try an explicit
> button-power=2
> as well

Now I've tried this too (+ dconf update + guest reboot). It has no effect, the shutdown button still doesn't work when on the graphical login / user selection screen. After login, shutdown works.

Comment 18 Bastien Nocera 2013-11-06 16:38:03 UTC
The problem is that gnome-settings-daemon disables the Power key when not in "normal" or "overview" modes:

This was meant to avoid people shutting machines down when on the screensaver. Except that that wouldn't stop somebody pressing the button for 5 seconds to switch the machine off anyway.

The fix is simple enough:
-        { POWER_KEY, NULL, N_("Power Off"), "XF86PowerOff", GSD_KEYBINDING_MODE_LAUNCHER },
+        { POWER_KEY, NULL, N_("Power Off"), "XF86PowerOff", GSD_KEYBINDING_MODE_ALL },

See the discussion in:

We'll probably need a few more changes on top of that patch to make sure that we never show dialogues in the lock screen though.

Comment 20 Bastien Nocera 2013-11-08 13:29:00 UTC
Turns out that's not quite enough, and there are a couple of bugs in gnome-shell that need fixing before that's possible.

I filed https://bugzilla.redhat.com/show_bug.cgi?id=1028451 about this.

Comment 22 Bastien Nocera 2014-06-16 14:45:40 UTC
*** Bug 1040307 has been marked as a duplicate of this bug. ***

Comment 23 Amit Shah 2014-12-03 08:53:22 UTC
*** Bug 1163712 has been marked as a duplicate of this bug. ***

Comment 24 Laszlo Ersek 2015-03-16 11:30:31 UTC
This bug is still present in RHEL-7.1.

I guess that's because blocking bug 1028451 has not been touched by its assignee ever since Bastien filed that bug, SIXTEEN months ago (see comment 20). Nice job!

Comment 27 Bastien Nocera 2015-03-31 14:38:00 UTC
This got fixed upstream, and will be in the rebased GNOME in RHEL 7.2.

Comment 35 Laszlo Ersek 2015-07-07 20:06:43 UTC
*** Bug 1231600 has been marked as a duplicate of this bug. ***

Comment 36 Ray Strode [halfline] 2015-08-17 20:56:25 UTC
*** Bug 1242075 has been marked as a duplicate of this bug. ***

Comment 39 errata-xmlrpc 2015-11-19 08:23:36 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.