Use pm-utils when suspending/hibernating

Bug #366119 reported by Michael Terry on 2009-04-24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
acpi-support (Ubuntu)
Steve Langasek
anacron (Ubuntu)
Martin Pitt
wicd (Ubuntu)
Colin Watson

Bug Description

Binary package hint: acpi-support

I ran into an issue with my HP Mini 1000 (which uses a customized version of Hardy) where if I was at the GDM screen and pressed Fn+F1 (the suspend button), the computer would suspend, but the screen would stay black on resume. This seemed like a classic video quirk issue.

Looking into it (not being very familiar with acpi-support), I discovered that acpi-support tries to do some very manual 'write to /sys/power/state' logic all by itself. It also has its own hook system in /etc/acpi/suspend.d (which surely isn't news to you, dear reader). Of course, it only uses this if something better isn't already running (g-p-m or kpowersave), like at the GDM screen where I was.

I thought, "Don't we have HAL for this, with its own, larger set of quirks?". And indeed, replacing's logic with a dbus call to HAL fixed the bug for me.

So I thought that it would make sense for acpi-support to prefer a call to HAL (or pm-utils) over its own hacked-up system. I believe HAL and friends are more actively maintaining quirks? HAL is certainly the path more frequently used since the user commonly goes through g-p-m. Seems odd to have two separate paths with their own quirks.

Is it true that in an ideal world, acpi-support would just depend on dbus/HAL or pm-utils and not have its own quirks? Or do they serve a valuable purpose? I know there's a Karmic blueprint that might talk about some of these issues (

But this bug is about the more conservative approach of just preferring HAL/pm-utils for suspend and hibernate. I'm attaching a debdiff that does this (and falls back to the current code if neither dbus/HAL or pm-utils is available).

Michael Terry (mterry) wrote :

Here's a debdiff and a bzr branch: lp:~mterry/acpi-support/prefer-hal-366119

Michael Terry (mterry) wrote :

Ah, I see there's already a spec very specific to getting rid of acpi-support quirks and using HAL instead:

Well, maybe this bug is a first step. Or maybe you folks want something more drastic?

On Fri, Apr 24, 2009 at 02:27:36PM -0000, Michael Terry wrote:
> I thought, "Don't we have HAL for this, with its own, larger set of
> quirks?". And indeed, replacing's logic with a dbus call to
> HAL fixed the bug for me.

Yes, and as a matter of fact, the existing quirks in acpi-support were
dropped in the jaunty cycle, thinking that we were done with using
acpi-support for suspend by default - the case of suspending from the gdm
screen was overlooked.

I think it would be fine to have acpi-support call pm-suspend or
pm-hibernate directly in these cases. Though this may need revision again
over the course of the karmic release cycle, since the new gdm, if it lands,
is supposed to me much more "desktop-y", and may handle such events

Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer
<email address hidden> <email address hidden>

Am I missing some reason that we would want to call the hal methods via dbus instead of just calling pm-* directly? If there isn't a reason for this, then I think we should just call pm-{suspend,hibernate} directly for simplicity's sake.

Either way, acpi-support should depend on pm-utils and/or hal/dbus to ensure that these functions don't fail when those packages are absent.

Changed in acpi-support (Ubuntu):
assignee: nobody → vorlon
importance: Undecided → Medium
status: New → Triaged
Michael Terry (mterry) wrote :

Well, I am not very familiar with internals of HAL, but my reading indicates that when HAL gets a request to suspend/hibernate, it does some stuff and then 'eventually calls pm-suspend'. For example, I assume pm-suspend doesn't know about HAL's quirks. So I figured there are HAL smarts that would be good to use if we can.

I don't think there's any reason for a Depend on anything. Maybe a Recommend. My patch at least cleanly uses the current code if dbus-send/the HAL daemon/pm-utils isn't installed.

Martin Pitt (pitti) wrote :

The patch looks ok to me, although I think that we could make it much simpler by ripping out the acpi-support fallback entirely (which is totally unsupported and broken now), and just call pm-{suspend,hibernate}. pm-utils makes sure to read the necessary quirks itself, so we don't even need the d-bus magic.

Not calling hal will also be more robust for the future when hal will be deprecated in favor of devicekit-power.

Martin Pitt (pitti) wrote :

Oh, and if we do that, we need to add a "Recommends: pm-utils" to gdm.

Michael Terry (mterry) wrote :

How's this? It is much more drastic, rips out the suspend.d and resume.d support entirely.

Would making a much simpler patch (akin to my original one) as an SRU for Hardy or Intrepid make sense? The 'suspend doesn't work right in GDM' might be worth it.

Michael Terry (mterry) wrote :

Uh, I meant Jaunty, not necessarily Intrepid. Forgot about Jaunty already. :)

Martin Pitt (pitti) wrote :

Thanks, Michael. This looks like a great cleanup patch for karmic.

If this is considered important enough for an SRU (which I'd agree to, since it is a regression compared to intrepid and earlier), the first patch seems appropriate, since it avoids messing with conffiles in a stable release.

Michael Terry (mterry) wrote :

To be clear, the 'suspend doesn't work amazingly @ gdm screen' bug is not a regression in Jaunty. That bug exists in Hardy, which is where I originally found it.

Michael Terry (mterry) on 2009-04-27
summary: - Prefer HAL when suspending/hibernating ourselves
+ Use pm-utils when suspending/hibernating
Steve Langasek (vorlon) wrote :

I still think having acpi-support depend directly on pm-utils is more appropriate than having gdm recommend it.

Steve Langasek [2009-04-28 3:47 -0000]:
> I still think having acpi-support depend directly on pm-utils is more
> appropriate than having gdm recommend it.

Did I say gdm? I meant acpi-support, of course, sorry.

Steve Langasek (vorlon) wrote :


Your branch looks awesome, thanks for the great work here! I only see one possible issue, which is:

+ rmdir --ignore-fail-on-non-empty /etc/acpi/resume.d
+ rmdir --ignore-fail-on-non-empty /etc/acpi/suspend.d

these commands will cause the preinst to fail if the directories simply don't exist, which though unlikely, is a perfectly valid state for the system to be in at this point. So I'm going to guard these with a pair of if [ -d ] checks.

Everything else looks great as far as an upload to karmic is concerned. Per Martin, if this is to be an SRU target the SRU branch should be less invasive.

Steve Langasek (vorlon) wrote :

whoops - good thing I did a test install of the packages. The preinst tries to remove /etc/acpi/resume.d/ and /etc/acpi/suspend.d/, which are not part of this package - so even though they're unmodified, the system detects them as modified and moves them aside, which will prevent anacron from properly cleaning them up later.

I've fixed the preinst to not touch these conffiles; opening a task on the anacron package to finish this up.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package acpi-support - 0.122

acpi-support (0.122) karmic; urgency=low

    - Don't use custom suspend/hibernate solution. Instead, call pm-utils.
      LP: #366119
  *,, resume.d, suspend.d:
    - Delete; no longer used
  * debian/dirs, debian/rules:
    - Don't install resume.d and suspend.d directories
  * debian/control:
    - Depend on pm-utils
  * debian/preinst:
    - Remove any existing resume.d and suspend.d files.

 -- Michael Terry <email address hidden> Mon, 27 Apr 2009 10:08:23 -0400

Changed in acpi-support (Ubuntu):
status: Triaged → Fix Released
Michael Terry (mterry) wrote :

Thank you Steve for the fixes. Since I don't think this qualifies for an SRU (not technically a regression, no loss of data (unless some other user is logged in when you suspend from GDM and can't wake up), no security issues, etc), I'm not going to nominate it.

But if ya'll nominate it for a past release, I can whip up a debdiff.

Michael Terry (mterry) wrote :

I've opened a couple tasks against both anacron and wicd, since they are the only other packages to install files into suspend.d or resume.d. Both packages also install an identical pm-utils hook, so they aren't broken now that we don't run those directories, but they should probably be cleaned up to not install the acpi scripts.

Martin Pitt (pitti) wrote :

I'll clean anacron, thanks for pointing out.

Changed in anacron (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Low
status: New → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package anacron - 2.3-13.1ubuntu7

anacron (2.3-13.1ubuntu7) karmic; urgency=low

  * Remove acpi-support integration, we have used pm-utils for a long time:
    - Drop debian/acpi.d.{suspend,resume}
    - debian/dirs: Drop etc/acpi*
    - debian/rules: Don't install acpi scripts any more
    - debian/anacron.postinst: Remove old acpi scripts on upgrade.
    - LP: #366119
  * debian/control: postfix -> default-mta. (See Debian #490785)

 -- Martin Pitt <email address hidden> Tue, 16 Jun 2009 10:52:00 +0200

Changed in anacron (Ubuntu):
status: In Progress → Fix Released
Titi Ala'ilima (tigretigre) wrote :

Any chance these fixes will make their way to Jaunty?

Michael Terry (mterry) wrote :

Titi, not really. These changes don't strike me as meeting the requirements of an SRU:

Colin Watson (cjwatson) on 2009-09-04
Changed in wicd (Ubuntu):
assignee: nobody → Colin Watson (cjwatson)
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package wicd - 1.6.1-3ubuntu1

wicd (1.6.1-3ubuntu1) karmic; urgency=low

  * Configure with --no-install-acpi, removing acpi-support integration.
    We've used pm-utils for some time now (LP: #366119).

 -- Colin Watson <email address hidden> Fri, 04 Sep 2009 16:37:00 +0100

Changed in wicd (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers