tracking down suspend/hibernate bugs?

Matt Price matt.price at
Mon Jan 14 06:51:48 UTC 2008

On Sun, 2008-01-13 at 21:51 -0600, Aren Olson wrote:
> In gutsy I believe the chain is this:
> gnome-power-manager -> hal
> (/usr/lib/hal/scripts/hal-system-power-suspend) -> acpi-support
> (/etc/acpi/

> most of the actual work occurs in acpi-support.
> hal may call a different tool than acpi-support if it is available
> though, see /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux
> for full details.

in hardy it appears that acpi-support has been cut out entirely in favor
of pm-utils -- see the attached hal-system-power-suspend-linux script.
i've flipped through the pm-utils code & can't see exactly how it's
determined what is used to make the actual suspend call -- for instance,
i'm not sure what I would do if i wanted to use a custom kernel with
tuxonice for suspend, which i think still works best if it's called by
the hibernate script.  

i alsoseem to have an odd problem -- if i choose 'suspend' from the
gnome 'quit' menu, then resume fails.  if, however, i suspend just by
closing the lid on my laptop, suspend and resume both succeed.  this
suggests to me that two different methods are being used, probably acpi
in the lid case and pm-utils in the gnome case.  seems to me this
shouldn't happen; again, i'm not quite sure what's going on.  

apt cache gives this list as the ubuntu maintainer of pm-utils; the
changelog suggests that the package has just been ported over unchanged
from debian.  if it's going to be the main power management tool, it
seems like an important piece of infrastructure; is anyone at ubuntu
watching over it at all?  if so, please let me know what i can do to
help with debugging and stuff.  

thanks as always,


> Aren Olson
> On Jan 13, 2008 7:42 PM, Matt Price <matt.price at> wrote:
> > hi,
> >
> > just upgraded to hardy and suspend-to-ram is broken again (as in feisty
> > & other releases)  i'm trying to figure out, again, how to track down
> > this bug but i'm not entirely sure what the current chain of events is
> > in the suspend process.  can someone point me to a location where the
> > process is described?  or suggest best practice for finding bugs of this
> > nature (in which resume is impossible, so messages e.g. from dmesg
> > or /var/log/messages don't get captured?
> >
> > thanks,
> >
> > matt
> >
> >
> >
> > --
> > Matt Price
> > matt.price at
> >
> > --
> > Ubuntu-devel-discuss mailing list
> > Ubuntu-devel-discuss at
> > Modify settings or unsubscribe at:
> >
Matt Price
matt.price at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hal-system-power-suspend-linux
Type: application/x-shellscript
Size: 2176 bytes
Desc: not available
URL: <>

More information about the Ubuntu-devel-discuss mailing list