Bug 813822

Summary: suspend doesn't work - it only turns off NetworkManager and runs screensaver
Product: [Fedora] Fedora Reporter: Petr Schindler <pschindl>
Component: pm-utilsAssignee: Jaroslav Škarvada <jskarvad>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 17CC: hughsient, jskarvad, mads, nphilipp, pknirsch, robatino
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-19 10:14:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 752650    
Attachments:
Description Flags
/var/log/messages
none
/var/log/pm-suspend.log none

Description Petr Schindler 2012-04-18 13:46:17 UTC 
Created attachment 578359 [details]
/var/log/messages

Description of problem:
When I try to suspend my laptop (from user menu -> suspend) it only turns off the NetworkManager, runs screensaver and then ... nothing. It doesn't suspend. When I log back to the desktop the Network manager is still sleeping.

My guess: It executes pre-suspend scripts but then it doesn't suspend. So it can't be woken and no post-suspend scripts are executed.

When I install from Fedora 17 Beta DVD it works. It stops working after updates (I have updates-testing enabled).

This is from /var/log/messages (the whole log is appended):
dbus[663]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.4" (uid=0 pid=647 comm="/usr/lib/systemd/systemd-logind ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.40" (uid=1000 pid=1222 comm="gnome-session ")

Version-Release number of selected component (if applicable):
Fedora 17 Beta with updates (with updates-testing enabled)
pm-utilsi-1.4.1-18.fc17.x86_64
gnome-session-3.5.0-2.fc17.x86_64
systemd-44-4.fc17.x86_64

How reproducible:
first suspend after boot

Steps to Reproduce:
1. Boot up the system
2. Try to suspend
  
Actual results:
It turns off the NetworkManager, runs screensaver and doesn't suspend. When I log back into system the network isn't working

Expected results:
laptop should be suspended and after waking up network should work properly

Additional info:
I propose this bug as blocker. It doesn't break any criterion, but suspend is default session managing action and so it should work properly (or at least basic functionality should work). Also we have Beta test case which is now broken: https://fedoraproject.org/wiki/QA:Testcase_desktop_login
Comment 1 Petr Schindler 2012-04-18 13:47:20 UTC 
Created attachment 578360 [details]
/var/log/pm-suspend.log
Comment 2 Nils Philippsen 2012-04-18 16:07:25 UTC 
Same here, Thinkpad T520 and these package versions:

pm-utils-1.4.1-18.fc17.x86_64
gnome-session-3.4.0-2.fc17.x86_64
systemd-44-4.fc17.x86_64
systemd-44-4.fc17.i686
kernel-3.3.1-5.fc17.x86_64
kernel-3.3.2-1.fc17.x86_64
Comment 3 Nils Philippsen 2012-04-18 20:24:42 UTC 
Some more data:

- I've seen this with all the above kernels and kernel-3.3.1-3.fc16.x86_64 (the left over from F-16 prior to the upgrade). It's unlikely that this is (just) a kernel issue as the same kernel suspended just fine before F-17.

- I've attempted suspending with "sh -x pm-suspend" and tailing /var/log/pm-suspend.log -- it seems that the sync just before "echo mem > /sys/power/state" hangs.

- Subsequent executions of the sync command hangs in the sync() call.

- "echo mem > /sys/power/state" hangs, a second attempt gives "device or resource busy"

- I've seen this in both Gnome Shell and XFCE

I'll set severity to high as this is crash-like behavior and not recoverable.
Comment 4 Nils Philippsen 2012-04-18 20:27:13 UTC 
I knew I forgot something: one or two times when testing this and then shutting down the system, it suspended the machine during shutdown, then when resuming finished shutting down and switched off. As if whatever caused stuff to be wedged was killed off, then pm-action could continue on its merry way and issue the suspend command.
Comment 5 Nils Philippsen 2012-04-19 10:14:20 UTC 
This is actually a deadlocked fusermount process and is fixed in selinux-policy-targeted-3.10.0-116.fc17, closing as duplicate.

*** This bug has been marked as a duplicate of bug 812588 ***