Description of problem: After maintenance (daily) I often reboot my system. After what appears to be normal shutdown/reboot/poweroff processing the system hangs. The last 3 messages are: systemd-shutdown[1]: /usr/lib/systemd/system-shutdown/nutshutdown failed with error code 1. systemd-shutdown[1]: failed to read reboot parameter file: No such file or directory systemd-shutdown[1]: Rebooting Version-Release number of selected component (if applicable): Kernel 4.7.0-0.git3.2-fc24.x86_64 How reproducible: Always Steps to Reproduce: 1.shutdown now or reboot or poweroff 2. 3. Actual results: Expected results: Additional info:
Observing the same bug with current Fedora 25 x86_64 rebooting on a MacBook Pro 2,1. However this reboot is after applying the a complete set of 'dnf group installs' from a clean install. From my past experience with this bug, you can 'wait it out' and the computer will complete the reboot in the middle of night. I have always assumed that on older slower hardware with massive software updates, there might be some cache clearing for the machine to work through, no?
Jack, I have seen this problem with FC 23/24/25 and 26(rawhide). Waiting it out doesn't seem to work. I get a hung system. Any other ideas would be welcome. George...
More info... I may have a problem with my system's sound system. Mplayer issues a system call (I think) for something prefixed by snd_pc. This seems to block and persist through out the life of the "current" boot. shutdown/reboot/poweroff all seem to see this block and hangs the system waiting for the blocked process to "hear" the kill signal. The only recourse I have found is to power cycle the system. My conclusions above are purely speculative... but, I have seen this a lot and when I disable the sound system or run mplayer with it's "-nosound" parameter, the problem doesn't appear. I have seen code on other systems (legacy) where the blocked process is removed from the list of processes. Therefore, shutdown/reboot/poweroff does not even see the blocked process and can complete "normally". This would be a wonderful capability to have on Linux/Unix systems. :-) If you want to close this bug please feel free to do that. Thanks, George...