I used to have Fedora 14 installed on this HP Compaq 610, and the suspend feature worked fine. Now that I’ve installed Scientific Linux 6.1 suspend doesn’t work anymore. How do I debug/fix it?
Answers:
Thank you for visiting the Q&A section on Magenaut. Please note that all the answers may not help you solve the issue immediately. So please treat them as advisements. If you found the post helpful (or not), leave a comment & I’ll get back to you as soon as possible.
Method 1
There are many ways to handle suspend and hibernate capabilities, many of the old methods are deprecated. This has made searching for solutions difficult, as it seems every solution is completely unrelated to the next. With that said…
The method currently recommended, advocated from http://pm-utils.freedesktop.org/wiki/, should be available for most recent distributions. I would first check if you have pm-utils installed, and if the included commands are operating as expected.
View if the package is installed, enter this command in terminal
rpm -qa | grep pm-utils
This should output the version you have installed. If you don’t get the expected output, you need to install the package.
sudo yum install pm-utils
Once you get that verified, test out your ability to suspend.
sudo pm-suspend
If You don’t suspend, and get no output why, check the your recent dmesg output
dmesg | tail -50
This should help get you started, once you get some clues its much easier to go further down the trail. Post back with comments regarding your results, I can get you through the rest.
Method 2
Try this as root:
PM_DEBUG=true pm-suspend
Then check /var/log/pm-suspend.log for hints on what might go wrong.
If you can suspend, but not resume, there’s a good article on the Ubuntu wiki on how to debug this problem.
Method 3
If you want only to get when you suspended/resumed the system, you can try this:
cat /var/log/syslog | grep 'systemd-sleep' | grep "Suspending|resumed"; Feb 7 10:44:23 dmatej-lenovo systemd-sleep[19900]: Suspending system... Feb 7 10:44:33 dmatej-lenovo systemd-sleep[19900]: System resumed. Feb 7 10:45:35 dmatej-lenovo systemd-sleep[20707]: Suspending system... Feb 7 12:58:39 dmatej-lenovo systemd-sleep[20707]: System resumed. Feb 7 14:42:55 dmatej-lenovo systemd-sleep[24690]: Suspending system... Feb 7 16:31:57 dmatej-lenovo systemd-sleep[24690]: System resumed.
Method 4
As is suggested by Mika, as root:
PM_DEBUG=true pm-suspend
Details within:
/var/log/pm-suspend.log
In this case you’re looking for where
[...] service [servicename] suspend suspend success
ends, and
[...] service [servicename] suspend resume success
begins. Somewhere in between you may find calls returning error, at which point
suspend is inhibited. In this case, you may have suspend changes being rolled back. Figure out what service call is throwing the error, open it up in vi and take a look at it.
I had the same problem where after installing xboxdrv on an Ubuntu 12.04, a call being made in a rule in /etc/pm/sleep.d/ was trying to stop a service that was never started or non-existent, in this case, xboxdrv. Turns out it could never be started in the first place, because there was no /lib/modules/uinput.ko module, because that module is merged into the kernel. This caused the case statement in /etc/pm/sleep.d/xboxdrv to throw an error when it case matches “suspend” to the call service xboxdrv stop. Prepending the line with # bypasses the statement, at the expense of having to unplug and re-plug your controller on suspend then resume.
Method 5
On my machine I had Vagrant/Virtualbox running. When I used vagrant halt to suspend all vagrant boxes, and checked with the Virtualbox -GUI tool that no boxes were running (or ps aux |grep -i vbox), pm-suspend started to work ok again.
All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0