Description of problem: Since F16 is out I have the problem, that my computer hangs when I want to shutdown/reboot. This happens if the computer run for several ours and also happens if it was just started and direclty told to shutdown again (even without logging in). It also doesn't matter if I boot to runlevel 5 (I'm using KDE) or booting to runlevel 3. Version-Release number of selected component (if applicable): kernel-PAE-3.2.7-1.fc16.i686 How reproducible: In about 9 of 10 shutdown/reboots the shutdown process hangs for 3-5 minutes. Steps to Reproduce: 1. Start computer and let F16 boot 2. Shutdown/reboot Actual results: When shuting down from runlevel 5, the F-logo shutdown-screen is shown. When I hit [ESC], I can see, where it hangs: Sometimes it hangs on a completely black screen and after 3-5 minutes it continues with Sending SIGTERM to remaining processes... Sending SIGKILL to remainging processes... But sometimes the hanging moment is between this two messages. Expected results: When telling the system to shutdown/reboot, it should directly do this - without a 3-5 minute hang. Additional info: I already opened bug 751060, but this was hijacked by others users having also shutdown problems, but with IMSM Raid. And I was told in comment 36 to open a new bug, because I don't have IMSM Raid.
Save this script as /lib/systemd/system-shutdown/debug.sh: #!/bin/sh mount / -o rw,remount dmesg > /dmesg.txt mount / -o ro,remount Make it executable (chmod +x /lib/systemd/system-shutdown/debug.sh). Then boot with the following kernel command line parameters: systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0 Reproduce the delay on shutdown. After booting back, attach the resulting /dmesg.txt file here. Thanks.
Created attachment 567400 [details] Debug dmesg output Find attached the requested output. I started the computer with the given kernel parameters to runlevel 5 and directly let the computer reboot (without logging into KDE).
NetworkManager did not exit within 90 seconds after getting SIGTERM, then a timeout kicked in. *** This bug has been marked as a duplicate of bug 739836 ***