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
Created attachment 578360 [details] /var/log/pm-suspend.log
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
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.
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.
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 ***