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.
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?
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.
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.
OK, giving g-p-m a bit more time works. Pressing the power button nicely shows the menu.
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.
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.
*** Bug 203995 has been marked as a duplicate of this bug. ***
ps aux | grep gnome-power-manager give just 'gnome-power-manager' without any options.
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 ?
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?
but it also seems to crash, I see the g-p-m icon disappear before it blanks the screen and shuts down.
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.
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 ?
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
> 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 ?
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.
Richard, any comment ?
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.
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.
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?
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.
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.
Hang fire. See if there is a hal event, because if there is, then it's easyfix.
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.
So we are just getting an ACPI event. This is getting odder. Let me see if I can reproduce when FC6F3 is released tmw.
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.
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
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.
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