From the Canyon Edge -- :-Dustin

Wednesday, February 25, 2009

Ubuntu Server: Suspend/Hibernate/Resume Call for Testing!

Late last week, Mark announced the next Ubuntu release, Karmic Koala. Mark noted that:
the best way to conserve energy is to go to sleep,
and these days even servers can suspend and resume,
so imagine if we could make it possible to build
a cloud computing facility that drops its energy use
virtually to zero
In December of 2008, I asked what you thought about suspending and hibernating Ubuntu Servers. While the "poll" wasn't unanimous, the overwhelming majority of you thought it might actually be useful in some situations.

It's not too early to start looking at this feature for Karmic. So I spent some time last week testing this, and I must say that I'm impressed with the very preliminary results. I was able to install the Ubuntu Jaunty Server on my hardware, both suspend and hibernate the system from the command line, and then remotely resume the system using wake-on-lan.

Impressively, my test system's power consumption is reduced by ~80% while in the suspended state, and can wake in ~5 seconds!

My test hardware is actually a desktop kit system (Asus P1-AH2, AMD x2 5800, 4GB, nVidia), running the Jaunty amd64 server.

At this point, I'm quite interested in gathering any feedback from the Ubuntu Server community on their experience suspending/hibernating/resuming the Jaunty Server on whatever hardware they might have. Here are some detailed instructions...

Server BIOS Setup

Check your BIOS for any relevant settings:
  • Make sure that wake-on-lan is enabled. This setting takes a variety of names in different BIOS implementations.
  • Make sure that low-power states are enabled (my bios had a setting for "S1 & S3" power states). Again, this may be labeled differently, but should be something along the lines of "Advanced Power Management".
Server OS Setup

Install Ubuntu Jaunty Server (i386 or amd64).

Install pm-utils and ethtool, both of which are now on the Jaunty Server CD.
  • sudo apt-get install pm-utils ethtool
Configure your network interface to wake-on-lan.
  • sudo ethtool -s eth0 wol g
I want this setting persistent across reboots, so I put this in /etc/rc.local.

Obtain the MAC address of your server, such that you can send the wake-on-lan magic packet from another system.
  • ifconfig eth0 | head -n1 | sed 's/^.*HWaddr //'
First, let ensure that wake-on-lan is working. Power this system down.
  • sudo poweroff
From another system, install the wakeonlan package.
  • sudo apt-get install wakeonlan
And send the magic packet to the MAC address you obtained earlier.
  • wakeonlan 00:11:22:33:44:55
If your server powers itself on, congratulations, wake-on-lan is working. If not, you need to get this working before you proceed further.

Once the server is back up, test suspend. Launch a program to run in the background, to ensure that the resume restored this state. And then run the pm-suspend command
  • screen top
  • (new window in screen-profiles)
  • sudo pm-suspend
Make sure that the system enters a lower power state. On my machine, the hard drives stop spinning, as well as the cdrom drive, cpu fans, case fans, etc. I tested resume twice, once by hitting the power button, and once by sending the wakeonlan signal.
  • wakeonlan 00:11:22:33:44:55
Then, test hibernate in a similar manner.
  • pm-hibernate
  • wakeonlan 00:11:22:33:44:55
Make sure that your context was saved, and the system is still running 'screen top' or whatever you chose to run.

Automated Testing

Next, I ran the automated test-suspend script developed by Andy Whitcroft on the Ubuntu Kernel team. I sent him a minor patch that tailored it a bit better for server testing. For details, see:
  • wget
  • sudo bash test-suspend --full --server

And I recorded my results at:
noting that this machine (Asus P1-AH2) was running the Ubuntu Server.

Do you have a server running Jaunty? Would you care to share your results?



  1. I dare say the reason why your initial testing worked on that asus rig might be due in some part to the existing work being done as part of the distro-neutral upstream hal project at I'm pretty sure I've seen other Canonical employees participating in that distribution-neutral upstream effort in the past contributing quirk fixes.

    You might want to consider contributing your server oriented testing scripts back up to the existing upstream hal quirk effort if you haven't already.

    It would be a real shame if Canonical's new focus on fixing the minority of hardware not already accounted for in the year+ of upstream hal-info work didn't make it back upstream.


  2. Jef-

    It works on my Asus P1-AH2 due to:
    by Andy Whitcroft (Canonical Kernel) and myself.

    Of course, this work has been pushed to the upstream kernel.

    The test script is also GPLv2:

    It is being pushed into the checkbox project:


  3. This comment has been removed by the author.

  4. That particular piece of hardware (Asus) required a kernel tweak for resume to totally work.

    I expect we'll find plenty more hiccups as we test this more comprehensively.

    In each case, I totally expect that we'll develop the patch against the Ubuntu kernel, and feed it upstream immediately upon verification.


  5. Afraid I haven't any test-hardware currently to help with this, but wanted to suggest that it could be nice to also test wake-on-RTC capabilities.

    Let's say you want your server to be up only during office hours or perhaps rather only for nightly backups; having it wake-up without any prodding over the LAN would be convenient for that.

    My home box has an Intel mainboard that doesn't even show this feature in the BIOS menu, but it works when set from within the OS! I actually learned about that on the Ubuntu wiki:

  6. Cool a comprehensive testing effort.
    Launchpad is going to collect the test results?

    Do you have the interaction defined on how would an upstream project developer will be able to pull relevant checkbox results out of lp?


  7. That's interesting. I've been thinking about acquiring or building a low-power server solution for the home, something that idles at less than 15 watts, equivalent to two night-light bulbs. Do you have any numbers yet on power consumption in hibernate state vs. full operation for your setup?

  8. Jef,

    As well as producing a local report, Checkbox feeds its results into Launchpad, which processes, stores, and soon will display them.

    Right now the only way to extract the data from Launchpad is to use the API, and that is primarily focused around extracting hardware data although it will expand.

    There are some samples in development for using launchpadlib to access the information in Launchpad.

  9. Joe-

    I have a "Watts Up" watt-meter here that I've used for some testing. Note that I am also using cpu frequency scaling, which helps quite a bit, even on a running system. Here's what I'm seeing (your mileage may vary):

    Running system (loaded): 85W
    Running system (idle): 55W
    Suspended system: 11W
    Hibernated system: 8W
    Powered off system: 8W


  10. Hi Dustin,

    I have been working on doing this for a lab full of headless servers (Dell GX270 boxes). I have been able to make them wakeup on unicast activity from suspend (it takes about 5 seconds) by echoing the correct interface name to /proc/acpi/wakeup and by using ethtool to set wol to ug. This is handier than havint to use a magic packet to wake on lan the computers. To the users it is transparent.

    I am now struggling with how to make them suspend on lack of unicast network activity or something else appropriate. I would be interested in any tips you or your readers have.

    I believe that making Ubuntu servers wake and sleep on lack of unicast network activity is well worth doing. I have a P4 at home that uses 220 watts (only the box) and only about 4 watts in suspend. At our electricity rates (7.8 cents/kwh) I could potentially save almost $150 a year in electricity. At the University where I work, we have nearly 1000 computers on campus, and folk tend to leave them running so they don't have to wait for boot up and so they don't have to set up their favorite applications again to where they left off the day before. So for our school alone, if we were able to make this work, it would be perhaps $100,000 a year, which is significant in terms of saving wasted energy as well.

    Wouldn't it be great if Ubuntu was a leader in this area?

    Best Regards,

    Rob Frohne

  11. Hi Dustin,

    I'm trying to get this working on my home server (not a clean Jaunty install, but an Intrepid install recently upgraded to Jaunty). When I execute pm-suspend I get absolutely nothing: no error message as well as no effect. My hardware is an old IBM board with i810 chipset and PIII 800MHz processor. Can you suggest how to start debugging?

    Thank you and regards.

  12. Antonio, find out first if your motherboard has the Wake-on-LAN feature and, if so, whether /any/ operating system released at the time the hardware was produced was able to put the machine into sleep or hibernate mode. If the motherboard doesn't have a built-in Ethernet connector, chances are that it doesn't support Wake-on-LAN, either. It sounds like it comes from an era (mid- to late 1990s) when few hard drives supported spin-down and spin-up commands. Power management in large integrated circuits for desktop systems also didn't start becoming a burning issue (pardon the pun) until the Pentium IV appeared on the scene, or thereabouts.

  13. I am just getting started with Ubuntu server by setting up my own home server on an old machine. I am really interested in the ability to automatically suspend/hibernate after the server has been idle for a given amount of time, then be able to wake on lan.

    As of yet, I can't find anything to have Ubuntu server automatically suspend/hibernate. Are there any tools that will do this?

  14. Scott,

    You're looking for the "powernap" package. Install that and see /etc/powernap/config for configuration.



Please do not use blog comments for support requests! Blog comments do not scale well to this effect.

Instead, please use Launchpad for Bugs and StackExchange for Questions.