Ubuntu Wiki

There seems to be quite a bit of discussion about suspend-to-ram and suspend-to-disk support in Feisty. I think a large portion of the disagreements are rooted in the fact the overall suspend process and support are largely inconsistent and undocumented. Therefore, in an attempt to foster useful discussion, I will try to document the overall method of how software suspend works in Ubuntu.

Relevant Packages

Starting software suspend

There are multiple methods of starting a software suspend procedure. Each is associated with a different user-interface state.

Default (acpi events)

In the absence of any other overriding policy, acpi-support has full control over the software suspend process.

There are two categories of acpi suspend events, and they respectively execute two scripts:

These scripts are either executed directly, or in-directly by a mapping of the third-party sleep/hibernate button events to the normal sleepbtn event.

GDM

GDM has menu-items specifically for "hibernate" and "suspend" (sleep). These call the powermanagement-interface directly via the following commands:

The powermanagement-interface scripts execute the acpi-support scripts with an override for any other policy.

Gnome

gnome-power-manager is the official policy and user-interface for power management in Gnome. When it is running, the several power management related acpi-support scripts specifically disable themselves. Their normal actions will not occur except when specifically requested via a "force" command-line option.

The software suspend policy of gnome-power-manager is actually handled by hal.

KDE

Software suspend policy

Once a software suspend has been requested, some program must perform the "policy" for it. That is, actually ensure the system is in a suitable state for suspension. And later, return the system to (roughly) the same state it was before the software suspend occurred.

acpi-support

These much maligned scripts now have a long history behind them, and apparently fairly rich support for a variety of hardware. However, they are also almost completely Ubuntu specific.

The two earlier mentioned scripts, /etc/acpi/hibernate.sh and /etc/acpi/sleep.sh handle the heavy lifting. Documenting their every contortion is beyond the scope of this article; however, the overall process is as follows:

hal

As hal is designed to be operating system agnostic, there is a (mostly dummy) front-end handler script initially called and then a specific worker script:

• is this the setup in feisty? On my edgy system scripts are in /usr/share/hal/scripts and there is no scripts/linux directory -- MattPrice

These scripts have several bugs and inconsistencies between them. (Free easy bug-fixing opportunity here!) However, in terms of Ubuntu, a selection process for what will perform the hiberate/suspend is performed:

1. powermanagement-interface

2. powersaved

3. (hibernate only) freedesktop's pm-utils (do you mean "suspend-to-disk only"?)

4. uswsusp

5. hibernate (suspend2)

6. acpi-support

7. Direct to /sys/power/state sysfs interface.

In a default Ubuntu installation, powermanagement-interface is installed and therefore will always win. This results in hal handing off policy back to acpi-support.

• Am I right in thinking this is a ranked ordering, so that installing hibernate on top of a default ubuntu system will never allow hibernate to take over the suspend process? --MattPrice

• If a user wants to make changes to the default suspend procedures, what's the right level at which to intervene? Is it possible to rationalize this system so that system-specific changes only need to be made to one set of scripts? --MattPrice

  • I filed a patch for that at https://bugs.launchpad.net/ubuntu/+source/hal/+bug/90425

kpowersave

As of 0.7.2, kpowersave also uses HAL

Kernel suspend technologies

Inconsistencies

• There does not appear to be a default handler for the hibernatebtn acpi event.

• acpi-support will use uswsusp for hibernation but not sleep.

Alternatives

Suspend2

Suspend2 is a kernel patch which enables a second suspend method at the kernel level. Because it uses encryption, it is generally somewhat quicker than swsusp, and it has a number of other features such as a pretty user interface. Some users also find that suspend2 is more reliable at suspending/resuming than swsusp, but this is almost always because those users use a different power-management interface -- the hibernate script package.

The complexity of the suspend management system and the multiple changes that are made to the system when suspend2 is added make it difficult to diagnose precisely why one method works when another does not. If the whole stack were made as implementation-agnostic as possible (e.g. if acpi-support would try suspend2 as well as ususp and swsusp, and if suspend2's more advanced configuration features were accessible somehow withing the default stack) would go a long way towards making suspend2 easier to use on ubuntu.

CategoryLaptop