Bug 203289 - gnome-power-manager crashes when power button is pressed
Summary: gnome-power-manager crashes when power button is pressed
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-power-manager
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
URL:
Whiteboard: bzcl34nup
: 203995 (view as bug list)
Depends On:
Blocks: 202880 203737
TreeView+ depends on / blocked
 
Reported: 2006-08-20 17:21 UTC by Jurgen Kramer
Modified: 2013-03-06 03:46 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-05-07 00:45:40 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
call shutdown method on gnome-power-manager (1.42 KB, patch)
2006-08-30 05:20 UTC, Matthias Clasen
no flags Details | Diff

Description Jurgen Kramer 2006-08-20 17:21:47 UTC
Description of problem:
Currently g-p-m is set to ask what to do when the power button is pressed. When
the power button is pressed g-p-m crashes

Version-Release number of selected component (if applicable):
gnome-power-manager-2.15.91-2.fc6

How reproducible:
always

Steps to Reproduce:
1. press power button
2. gnome-power-manager icon disappears
3.
  
Actual results:
g-p-m crashes

Expected results:
Asks what to do, shutdown, reboot, hibernate...

Additional info:
When g-p-m is set to shutdown when the power button is pressed. The system shuts
down as aspected.

Comment 1 Richard Hughes 2006-08-20 17:33:33 UTC
If you 'crash' gnome-power-manager, and then open a terminal, type
'gnome-power-manager --verbose --no-daemon' and then press the power button,
what is the output?

Comment 2 Jurgen Kramer 2006-08-20 18:05:12 UTC
OK, when started from a terminal with --verbose --no-daemon it actually asks
what to do.

[watch_device_condition_cb] gpm-hal.c:917 (20:08:49):    emitting
device-condition : /org/freedesktop/Hal/devices/acpi_PWRF, ButtonPressed (power)
[hal_device_condition_cb] gpm-hal-monitor.c:267 (20:08:49):     
udi=/org/freedesktop/Hal/devices/acpi_PWRF, condition=ButtonPressed, details=power
[emit_button_pressed] gpm-hal-monitor.c:198 (20:08:49):  emitting button-pressed
: power (1)
[hal_button_pressed_cb] gpm-power.c:1695 (20:08:49):     emitting button-pressed
: power (1)
[power_button_pressed_cb] gpm-manager.c:1708 (20:08:49):         Button press
event type=power state=1
[gpm_screensaver_poke] gpm-screensaver.c:406 (20:08:49):         poke
[power_button_pressed] gpm-manager.c:1570 (20:08:49):    power button pressed
[manager_policy_do] gpm-manager.c:894 (20:08:49):        policy:
/apps/gnome-power-manager/action_button_power
[gpm_syslog] gpm-debug.c:140 (20:08:49):         Saving to syslog: GNOME
interactive logout because the power button has been pressed
[gpm_info_event_log] gpm-info.c:611 (20:08:49):  Adding 11 to the event log
[gpm_info_data_add] gpm-info-data.c:327 (20:08:50):      Using 4 lines
[gpm_info_data_add] gpm-info-data.c:327 (20:08:50):      Using 4 lines
[gpm_info_data_add] gpm-info-data.c:327 (20:08:50):      Using 4 lines

When started from a terminal without any options I does not respond (nor
crashes) when the power button is pressed. But when I press it a second time the
 "are you sure..." message appears.


Comment 3 Richard Hughes 2006-08-23 07:03:50 UTC
Ohh, the button event won't register for a few seconds after you start g-p-m,
thanks to the grace time that g-p-m gives to the power subsystem (acpi etc). I
wouldn't mind betting that you can reproduce the crash by doing
'gnome-power-manager --verbose --no-daemon --sm-disable"

If so, open gnome-session-properties, click startup programs, and see if
gnome-power-manager is being started with --sm-disable.

If it is, then remove the option.


Comment 4 Jurgen Kramer 2006-08-24 17:01:51 UTC
OK, giving g-p-m a bit more time works. Pressing the power button nicely shows
the menu.


Comment 5 Jurgen Kramer 2006-08-24 18:22:53 UTC
Hmm, unfortunately it still crashes. I check gnome-session-properties, g-p-m is
not started with --sm-disable.

And yes, starting 'gnome-power-manager --verbose --no-daemon --sm-disable' does
also crash g-p-m.

Comment 6 Richard Hughes 2006-08-25 06:44:16 UTC
Okay, can you do logout, login, open a terminal and do:

ps -aux | grep gnome-power-manager

to see what options are being set. Thanks.

Comment 7 Richard Hughes 2006-08-25 06:44:33 UTC
*** Bug 203995 has been marked as a duplicate of this bug. ***

Comment 8 Jurgen Kramer 2006-08-25 19:41:17 UTC
ps aux | grep gnome-power-manager give just 'gnome-power-manager' without any
options.


Comment 9 Matthias Clasen 2006-08-28 15:34:29 UTC
Hmm, I remember that I saw this crash earlier, but I can't reproduce it right now.
Do you still see it, and if yes, do you have more detailed reproduction
instructions ?

Comment 10 Jurgen Kramer 2006-08-28 18:17:58 UTC
Funny, with gnome-power-manager-2.15.92-2.fc6 when I press the power button it
just shuts down the machine. This is with the option "When power button is
pressed" set to "Ask". New bug?


Comment 11 Matthias Clasen 2006-08-28 19:26:36 UTC
but it also seems to crash, I see the g-p-m icon disappear before it blanks the
screen and shuts down.

Comment 12 Matthias Clasen 2006-08-28 19:35:13 UTC
hmm, this only happens with the g-p-m thats started at login. 
If I manually start g-p-m inside the session, it brings up the logout dialog
just fine.

Comment 13 Matthias Clasen 2006-08-28 20:13:09 UTC
Ok. Looking into this a bit, what we found is"

a) g-p-m tries to get power button press events from hal (via acpi, presumably)
  and if configured to "ask", asks the session manager to save the session 
  interactively, which presumably brings up the old gnome logout dialog. If it
  is configured to "shutdown", it just shuts down without any sesssion saving.

b) gnome-settings-daemon grabs the power button keysym and callss
   gnome-session-save --kill, which should have pretty much the same effect.

Conclusions:

- If g-p-m gets involved when the power button is pressed depends on what kind
  of events the power button generates. For all we know, this varies between
  machines.

- If g-p-m is configured to shutdown, you loose your unsaved changes when 
  you press the power button, even if you have configured gnome-session to
  automatically save the session on logout.

Proposals:
- Make gnome-session defer the handling of the power button to g-p-m, by
  invoking a suitable dbus method. This ensures that regardless which way
  the power button event takes, it gets handled by g-p-m.
- g-p-m should non-interactively save the session in the shutdown case. 
  Presumably there is a fast-saving option in XSMP for running-out-of-power
  situations, though I dcn't know if anybody pays attention to that.
 
How does that sound, Richard ?




Comment 14 Richard Hughes 2006-08-28 20:53:28 UTC
Matthias, I think g-s-d should call Shutdown [1] -- agreed this is a bit of a
mess where some machines generate acpi events and some produce x scancodes.

As for the saving of session, by default g-p-m saves the session, but in CVS
head this is configurable in gconf. ACPI *should* really send out events as
keycodes so we don't have to play this game, and I'm pretty sure this is the
direction the the acpi layer is heading.

As for running out of power, there is a quick shutdown option that g-p-m uses on
ciritical power state, altho that saves the state also (which some users may not
want)

I agree, g-p-m should handle the shutdown event as it's more of a position to
decide what to do than g-s-d.

Does that help?

Richard.

[1]
http://cvs.gnome.org/viewcvs/*checkout*/gnome-power-manager/docs/dbus-interface.html#pm-method-Shutdown

Comment 15 Matthias Clasen 2006-08-29 05:18:50 UTC
> As for the saving of session, by default g-p-m saves the session, but in CVS
> head this is configurable in gconf. ACPI *should* really send out events as
> keycodes so we don't have to play this game, and I'm pretty sure this is the
> direction the the acpi layer is heading.

Hmm, in manager_policy_do, I see

        } else if (strcmp (action, ACTION_SHUTDOWN) == 0) {
                manager_explain_reason (manager, GPM_GRAPH_EVENT_NOTIFICATION,
                                        _("Shutting down computer"), reason);
                gpm_manager_shutdown (manager, NULL);
        } else if (strcmp (action, ACTION_INTERACTIVE) == 0) {
                manager_explain_reason (manager, GPM_GRAPH_EVENT_NOTIFICATION,
                                        _("GNOME interactive logout"), reason);
                gnome_client_request_save (gnome_master_client (),
                                           GNOME_SAVE_GLOBAL,
                                           TRUE, GNOME_INTERACT_ANY, FALSE, TRUE)

This looks to me as if we are saving the session interactively on "ask",
but just showdown without saving in the case of "shutdown".

Wrt. making this configurable, aren't we doing double configuration here ?
I thought gnome_client_request_save already respects the gnome-session
gconf key for saving the session at logout ?

Comment 16 Matthias Clasen 2006-08-30 05:20:08 UTC
Created attachment 135185 [details]
call shutdown method on gnome-power-manager

Here is a patch to make gnome-settings-daemon call Shutdown via dbus. 
Unfortunately this doesn't quite work as intended, since Shutdown really
does shutdown, no questions asked. What we really want is to call
power_button_pressed, which is the function where g-p-m applies its
policy to power button presses.

Comment 17 Matthias Clasen 2006-09-05 17:47:27 UTC
Richard, any comment ?

Comment 18 Richard Hughes 2006-09-08 14:23:31 UTC
Sorry mclasen, I've been stressed out of my *face* for the last couple of weeks.

With my long term hat on, what is the plan? Who handles the power button. At the
moment g-p-m handles the dbus-ified version from acpi and pmu and g-s-d handles
the keycode. That's just wrong.

Can g-p-m not just listen for the keycode (I've no idea how to do this) and then
relinquish g-s-d of the responsibility of this (and reboot) key?

Richard.


Comment 19 Matthias Clasen 2006-09-08 16:04:02 UTC
Yes, that is possible. Ray is supposed to rework the way we handle multimedia
keys by having g-s-d just set the keysyms in gconf, and then have the multimedia
apps use the keysyms from gconf and do the grabbing themselves. We can certainly
use the same approach for the power button. Unfortunately, the action in
the keybinding capplet is somewhat misnamed ("Logout"), but that is a different
issue.

Comment 20 Richard Hughes 2006-09-08 16:17:37 UTC
So how can g-p-m grab the key press? Have you got any example code I can look
at? If I add the grabbing code to g-p-m, then all we have to do is comment out
the key handling code in g-s-d (and remove the logout ui from the keybinding
capplet) and then we are sorted, right?


Comment 21 Richard Hughes 2006-09-12 13:12:47 UTC
Jurgen, if you do "lshal -m" on a terminal, and then press the power button,
what do you get? I'm sure Hal is meant to proxy the power button for us, as a
dbus ButtonPressed condition.

Sortof like udi="foo_Kbd_Port_logicaldev_input", details="sleep" which g-p-m
should pick up.

Richard.


Comment 22 Matthias Clasen 2006-09-12 15:09:21 UTC
Richard, we will probably leave the Logout action in the keybinding capplet, so 
users have a chance to assign the keysym that their power button produces (since
our keymaps are not good enough to assume that this will always work out of the
box), but we'll remove the key grabbing from g-s-d, and make g-p-m get the
keysym from gconf and grab it itself.

We'll put a patch here as soon as Ray gets back to this.

Comment 23 Richard Hughes 2006-09-12 15:17:35 UTC
Hang fire. See if there is a hal event, because if there is, then it's easyfix.

Comment 24 Jurgen Kramer 2006-09-12 16:56:07 UTC
I managed to get the following from lshal -m:

Start monitoring devicelist:
-------------------------------------------------
acpi_PWRF condition ButtonPressed = power

I can only get this after I first killed g-p-m and restarted, otherwise the
machine will just shutdown and I cannot read fast enough.


Comment 25 Richard Hughes 2006-09-13 11:02:10 UTC
So we are just getting an ACPI event. This is getting odder. Let me see if I can
reproduce when FC6F3 is released tmw.

Comment 26 simon 2006-11-16 22:20:13 UTC
I'm having similar issues on FC6, I press the power button and gpm closes. I had
to disable the acpid power.conf script to avoid powering the machine straight off.

Comment 27 rizo83 2007-04-05 19:01:23 UTC
Have this issue as well.  My ugly work around was updating
/etc/acpi/events/power.conf with the following: 

event=button/power.*
action=/bin/ps awwux | /bin/grep gnome-power-manager | /bin/grep -qv grep ||
/usr/bin/gnome-power-manager || /sbin/shutdown -h now

Comment 28 Bug Zapper 2008-04-03 17:59:58 UTC
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 29 Bug Zapper 2008-05-07 00:45:38 UTC
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp


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