Red Hat Bugzilla – Bug 173639
Suspend and Hibernate from GPM menu do nothing
Last modified: 2013-03-13 00:49:15 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051103 Fedora/1.5-0.5.0.rc1 Firefox/1.5
Description of problem:
My notebook (Hewlett Packard ZD7000 CTO) will both suspend and hibernate when one of the following commands are executed:
echo "mem" > /sys/power/state
echo "disk" > /sys/power/state
Clicking Suspend or Hibernate on the GPM menu cause the screensaver to activate and nothing else.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Click Suspend or Hibernate from GPM menu.
2. Notice screensaver activates but nothing else.
Expected Results: Computer should suspend or hibernate.
rpm -q hal dbus
Nothing is logged by syslog - not that I've been able to find anyway. I see a new version of GPM (0.3) is released upstream. Maybe it will work.
Can you please attach a HAL debug trace (information here:
http://www.gnome.org/projects/gnome-power-manager/bugs.html) when you try to
suspend or hibernate. Also, what version of pm-utils have you got installed?
Many thanks, Richard.
Created attachment 121267 [details]
Created attachment 121268 [details]
Ok, you're going to love this. When I try to hibernate after the system is
started, it fails every time. If I kill hald and then start hald and
gnome-power-manager as directed on the bugs page, it works flawlessly every
time. I've attached the hald and gnome-power-manager output anyway, although
it's probably useless because it succeded every time I captured the output.
I also upgraded to todays rawhide pm-utils (pm-utils-0.06-3) and it had not
effect on either scenario.
Recommended additional data:
[root@localhost ~]# for i in /proc/acpi/battery/*/*; do echo $i; cat $i; done
design capacity: 6450 mAh
last full capacity: 1984 mAh
battery technology: rechargeable
design voltage: 14800 mV
design capacity warning: 300 mAh
design capacity low: 200 mAh
capacity granularity 1: 32 mAh
capacity granularity 2: 32 mAh
model number: 02NT
serial number: 10513
battery type: LION
OEM info: DYNA-SON
capacity state: ok
charging state: charged
present rate: 0 mA
remaining capacity: 1984 mAh
present voltage: 16576 mV
Okay... I'm at loss to explain that!
Can you try getting some debug data from the startup created hald by changing
daemon --check $servicename $processname --retain-privileges
daemon --check $servicename $processname --retain-privileges --use-syslog
and then configuring syslog to catch the new stuff.
Also, are you running SELinux?
I AM running SELinux (targeted-enforcing) and it does seem to make a difference.
If I change SELinux to permissive, the system will hibernate. If we are to go
on the assumption that something is being denied when run with enforcing - why
don't I see it in syslog?
Have you tried adding the extra stuff here?
Altho it should show up in the SELinux log file as denied. Might be worth
buzilla'ing the selinux component.
Recent updates to rawhide have resolved this issue, although I'm not sure how or
Occasionally, I do a selinux relabel. I did it with this last update as well.
After the relabel, hibernate works perfectly. After I reboot however, it's back
to the same behavior as before.
Please note, this is an advancement from the previous situation, because I had
tried relabel several times.
To answer comment #7 - no, I haven't changed my selinux policy, I'm just running
the stock policy.
I'm guessing that this is almost certainly a selinux issue now, given the recent
Urm.. It soulds like hald and selinux are not playing nicely. What selinux
denied messages do you get when running hald in restrictive mode? Might be worth
starting a bug for the selinux-policy component so it gets seen by some selinux
Todays rawhide update resolved this completely. I've tested it a half dozen
times or so now across multiple reboots and haven't seen any of the previous
Of course ultimately we want to take this out once Hybernate and Suspend are
working good on most laptops. The idea is many people don't know what they are
(and the shouldn't have to know). I even get confused which one is which so
seeing them in the UI sucks. Ultimately if I shut my lid the laptop should
hybernate and after a certaint amount of time or battery charge it should wake
up and then suspend itself to swap. But I digress and this bug can be closed.