g-p-m reports Problem with Suspend even on success.

Bug #32143 reported by Paul Sladen on 2006-02-20
This bug affects 2 people
Affects Status Importance Assigned to Milestone
hal (Ubuntu)

Bug Description

After selecting the menu-picture for suspend, the Thinkpad suspends and goes to sleep. The machine then unsuspends and after returning to the desktop g-p-m pops up a box saying the were Problems with suspend but not elaborating on them.


AFAICT (in luser mode) it went fine and I'm not sure what to do if I follow the link to the FAQ.

Richard Hughes (richard-hughes) wrote :

Can you attach the output of gnome-power-manager --no-daemon --verbose (over a startup, suspend, resume cycle) to this bug please.

$ killall gnome-power-manager
$ gnome-power-manager --no-daemon --verbose 2>&1 | cat | tee g-p-m-suspend-log.txt

Richard Hughes (richard-hughes) wrote :

Odd, HAL really did tell g-p-m that there was an error:

[gpm_hal_suspend] gpm-hal.c:202 (17:52:52): An unknown error occured
[gpm_hal_suspend] gpm-hal.c:205 (17:52:52): org.freedesktop.Hal.Device.SystemPowerManagement.Suspend failed (HAL error)

Can you do:

/usr/sbin/pmi action suspend force
echo $?

please, and tell me the result.

Paul Sladen (sladen) wrote :

$ sudo /usr/sbin/pmi action suspend force ; echo $? > result
$ cat result

^^ works fine, but without the sudo (the 'cat' is to stop 'su' asking for passwords...) then the following fails, but still cleanly exits:

$ cat | /usr/sbin/pmi action suspend force ; echo $? > result
$ cat result

Richard Hughes (richard-hughes) wrote :

Odd. Can you add some debuging into hal-system-power-suspend and work out why it's not returning cleanly? Perhaps the pmi command is not being fired, but the /sys/power/state file is being used.
A side issue, you've not got powersaved installed, or pm-utils, right?

Thanks, Richard.

I can confirm this, I get the same results with the pmi command, attached is the output from "gnome-power-manager --no-daemon --verbose"

I have a Samsung X20.

Changed in gnome-power-manager:
status: Unconfirmed → Confirmed
Martin Bergner (martin-bergner) wrote :

Ok, I now know that the pmi command is invoked and does return with errorcode 0. (Added a line to the script to test it), so the error is not in hal-system-power-suspend, that script returns with $RET= 0;

Can you tell me what scripts are called so that I can take a look at it? (Or at least tell me the highest, than I can go downwards)

Paul Sladen (sladen) wrote :

Seems to be reported on this wiki page too:


Richard Hughes (richard-hughes) wrote :

>Can you tell me what scripts are called so that I can take a look at it? (Or at least tell me the highest, than I can go downwards)

The hal-system-power-sleep script is the only script that HAL calls for a sleep event.

You might want to look at http://webcvs.freedesktop.org/hal/hal/hald/ , hald_dbus.c (hald_exec_method_cb)

You might also want to try and find out which [dbus_message_new_error (message, "org.freedesktop.Hal.Device.UnknownError", "An unknown error occured");] statement gets executed.

But before you do any of that I would reccomend trying CVS HAL, and checking that the error hasn't been fixed already.


Well, I haven't had a chance to look into it yet, (partly because I need to figure out how to install a modified version of hal so that it still works) but after upgrading to the latest g-p-m and dbus/hal I also get the failed message after hibernating. Before that, I only got it after suspending.

My versions:
dbus: 0.60-2ubuntu12
hal: 0.5.6-4ubuntu3
g-p-m: 2.13.91-0ubuntu2

You can disable the warning now with /apps/gnome-power-manager/notify_hal_error if you want a quick fix.

You'll have to be using todays CVS tho :-)


Daniel Silverstone (dsilvers) wrote :

The version richard was referring to is now in dapper. can you please try again and see if there are still problem with it reporting incorrectly. If so, does that gconf key help?

Is there any gain in reporting this to the user or should we default to suppressing this notification?

Paul Sladen (sladen) wrote :

The problem is that it's comforting for the user to know that the computer realised it didn't manage to sleep (*if* that was the case).

I think the link to the *URL* should be suppressed or changed to a link to Malone in the pre-release versions. (I followed the URL and it contained very little relevant or useful, just a generic page with directly no matching FAQ entries).

I'm tempted to agree that having the computer lie unintentionally is slightly worse than having it say nothing at all (or is this the MacOS approach).

Because the message is being triggered incorrectly. David Zeuthen has just found the bug in the glib dbus API. See http://bugzilla.gnome.org/show_bug.cgi?id=332888

I can update the faq page if so desired.

With the new version, I don't get the error message anymore

That comment was way to fast. I don't get the message if I suspend and immediately wake up again, but if I wait a while, it's still there, just as it says in the bug ... .

Steve Alexander (stevea) wrote :

I'm seeing this problem with the latest packages for Dapper, on a Dell Latitude X1.

The incorrect message is presented if I suspend using the fn+Esc "stand by" key, but no message is presented if I suspend using the "log out" menu item in the system menu.

Paul Sladen (sladen) wrote :

Is this bug still present? There have been quite a few updates to gnome-power-manager, which may have cleared this issue.

Mary Gardiner (puzzlement) wrote :

I still see this when suspending via a lid close. Not 100% reproducible, probably occurs on 50% of suspends.

Stefan Bethge (kjyv) wrote :

I can confirm this behaviour, whether short or long standby time. No difference if I use logout menu or fn-esc (there probably shouldn't be as the same script is called...?)
However, this message wasn't there one or two package versions of g-p-m before (and had been before this...).

Jani Monoses (jani) wrote :

happened here as well, daily of May the 20th, HP Nx8220 laptop.

Gintautas Miliauskas (gintas) wrote :

Happens here too on my Toshiba A15-S157.

Jeffrey Baker (jwbaker) wrote :

From the marked duplicate, I'll add that this also happens with about 50% frequency on PPC (PowerBook G3).

Paul Sladen (sladen) wrote :

Thinking about this; the only way to get the result is return code from doing:

  echo mem > /sys.../

Depending on whether this command returns success or not, you can tell whether we're returning from Resume, or a failure.

Riccardo Setti (giskard) wrote :


is this problem fixed with g-p-m 2.16.1?

Should be:

Version 2.16.1

Released September 29, 2006


 - Use the step value we computed (rather than one) to fix pressing
   brightness-down on the Macbook Pro. (David Zeuthen) #358067
 - Remove the FIXME to fix #334212. It's breaking more laptops that it
   was intended to fix and also breaks my (already broken) iBook.
 - Also ignore DBUS_GERROR_REMOTE_EXCEPTION as this prevents the
   'HAL failed to suspend' when actually it suspended fine but the bus
   timed out.
 - Fix a couple of small memory leaks where we don't free an icon name.
 - Don't rescan buttons every minute. #356170.
 - Fix hotplug add and remove of wireless mice.
 - Add the new battery types so we don't print a warning with
   newer than HAL
 - Increase dep of libgnome to 2.14.0 because we are using
   GNOME_PARAM_GOPTION_CONTEXT, which was introduced in 2-14
   (Mart Raudsepp) #355437

Sitsofe Wheeler (sitsofe) wrote :

I don't think this is fixed. I see the following screenshot in Feisty:
(from Bug #110071 )...

Sitsofe Wheeler (sitsofe) wrote :

(note this only happens on long hibernates of over 6 hours or so)

reh4c (gene-hoffler) wrote :

Please see my comments here: http://bugzilla.gnome.org/show_bug.cgi?id=447319
My iBook g4 gives me suspend errors with Feisty.

Jacob Emcken (jacob-emcken) wrote :

I dunno if this is the same bug but I see behavior alike the above described in my newly installed Gutsy.

I have attached output from "gnome-power-manager --no-daemon --verbose 2>&1".

/usr/sbin/pmi action suspend force exits cleanly

I have the following installed:

    dbus 1.1.1-3ubuntu1
    gnome-power-manager 2.19.6-0ubuntu2

Jacob Emcken (jacob-emcken) wrote :

This is how the error presents itself

Tom Vetterlein (smbm) wrote :

I think I have just filed a duplicate of this:


Not completely certain, if it does turn out to be a duplicate then apologies.

Scott Robinson (scott-ubuntu) wrote :

This occurs because libhal-glib/libhal-gpower.c:hal_gpower_has_suspend_error and :hal_gpower_has_hibernate_error check for the existence of "/var/lib/hal/system-power-suspend-output" and "/var/lib/hal/system-power-hibernate-output" respectively.

Specifically, if the respective file exists, then the suspend is considered to have errored.

Matteo Z (matteozandi) wrote :

I have the very same problem with gutsy and a toshiba M40-281. Suspend didn't work with previous Ubuntu version, but now finally does :)

Joseph Garvin (k04jg02) wrote :

I have this problem as well with the binary nvidia driver on a Dell Vostro 1400 (which AFAIK is hardware identical to the Inspiron 1420 officially supported by Ubuntu).

This bug is almost two years old and I'm seeing it on a new Hardy installation as of today. Please let me know if I should file any information (I'm on a lifebook p7010) to help debugging, or if this bug is just being ignored for some reason.

Hans Deragon (deragon) wrote :

This problem persist in Hardy Heron Alpha 4. As usability goes, this is one area that need to be fix. Hard to sell Ubuntu's stability when errors are erroneously reported. This bug is very visible to users.

Hans Deragon (deragon) wrote :

The only entries in syslog regarding this problem are:

Feb 12 08:38:17 <hostname> gnome-power-manager: (hans) Resuming computer
Feb 12 08:38:17 <hostname> gnome-power-manager: (hans) suspend failed

...not very helpful. Hardy Heron 08.04 A4 (Alpha 4).

Ted Gould (ted) wrote :

I'm moving the assignment of this bug to HAL. It seems that in most cases the GPM report shows that it got an error from HAL. If those who are still seeing this could test it in Hardy with the most recent HAL, as there are many suspend updates that recently appeared in HAL.

Thanks. Ted.

Pat Double (patdouble) wrote :

I did a hibernate cycle yesterday with the latest Hardy and am still having this problem. Should I run the debug log with gnome-power-manager, or do you have enough info?

Still happening in Hardy, and I installed today's HAL update earlier this afternoon, so whatever was changed in the latest release didn't fix the bug. This is really getting to be quite irksome.

Alex Wauck (awauck) wrote :

This still happens sometimes on both of my machines. Everything is completely up-to-date.

Alex Wauck (awauck) wrote :

I'm pretty sure this bug is fixed.

No, I'm seeing this bug on my desktop again after an update to Karmic. I can't suspend but after resuming from hibernating, I get an error box popping up and saying something about a failure. As far as I can tell, my system works flawlessly.

Jacopo Moronato (jmoronat) wrote :

This began to happen on my laptop, with Lucid. It also seems to appear on resume after long hibernate/suspend sessions.

Hans Deragon (deragon) wrote :

I do not see this bug with a ThinkPad T61p running Natty Narwhal 11.04.

dino99 (9d9) wrote :
Changed in hal (Ubuntu):
status: Confirmed → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.