Description of problem: After a machine was booted using systemd-38-3.fc17 a 'reboot' command typed on a text console by root terminates few services and the last line printed on a screen is: network [1331]: Shutting down interface eth1: [OK] and nothing happens afterwards. The only way out, after a long wait, is a power switch. There were no problems with rebooting or shutting down when systemd-37-4.fc17 and reverting restores sanity. Version-Release number of selected component (if applicable): systemd-38-3.fc17 How reproducible: on every attempt Additional info: When system was booted with systemd-37-4.fc17 and systemd replaced with systemd-38-3.fc17, and ONLY then, then at least some "Failed at step STDOUT spawning" were displayed on a screen and logged before a machine refused to reboot. I am not entirely sure if these were the same messages but at least this was logged: systemd[5185]: Failed at step STDOUT spawning /lib/systemd/systemd-logind: No such file or directory systemd[5202]: Failed at step STDOUT spawning /bin/umount: No such file or directory systemd[5204]: Failed at step STDOUT spawning /sbin/swapoff: No such file or directory systemd[5206]: Failed at step STDOUT spawning /sbin/swapoff: No such file or directory systemd[5208]: Failed at step STDOUT spawning /sbin/swapoff: No such file or directory systemd[5212]: Failed at step STDOUT spawning /sbin/modprobe: No such file or directory right after this showed up in logs: systemd[1]: Reexecuting. systemd[1]: systemd 38 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +SYSVINIT +LIBCRYPTSETUP; fedora) ed: systemd-38-3.fc17.x86_64 ed: systemd-sysv-38-3.fc17.x86_64 All later attempts to reboot left me entirely in a dark about possible reasons.
Oh, when booted to level 1 then both shutdown and reboot work without any issues. Only when starting a machine in a way one could want it possibly use when this goes wrong.
Try adding these two lines to /lib/systemd/system/syslog.socket: Conflicts=shutdown.target Before=shutdown.target (as in http://cgit.freedesktop.org/systemd/systemd/commit/?id=ead51eb4ed55981f290e40a871ffbca6480c4cd3)
... and don't forget to do 'systemctl daemon-reload' before you reboot after editing.
(In reply to comment #2) > Try adding these two lines to /lib/systemd/system/syslog.socket: > > Conflicts=shutdown.target > Before=shutdown.target Yes, this makes a substantial difference. Thanks. After "Shutting down interface ..." line I see now Sending SIGTERM to remaining process and the rest of shutdown or reboot follows as expected. I still think that it is too easy to get something wrong here and the whole design is too brittle. I had cases (not understood, not repeatable) when systemd died for unfathomable reasons and a machine was sort of running but becoming impossible to reboot other than by pulling a plug.
syslog-related problems are often nasty. Try sending a SIGSTOP to the syslog daemon sometime ;-) When running Rawhide, I definitely recommend having SysRq enabled for the Alt+SysRq + {S,U,B} emergency combination.
(In reply to comment #5) > When running Rawhide, I definitely recommend having SysRq enabled for the > Alt+SysRq + {S,U,B} emergency combination. In theory this should be somewhat different from "pulling a plug"; in practice not necessary. :-)
(In reply to comment #5) > syslog-related problems are often nasty. Try sending a SIGSTOP to the syslog > daemon sometime ;-) > > When running Rawhide, I definitely recommend having SysRq enabled for the > Alt+SysRq + {S,U,B} emergency combination. This is new to me A pointer?
(In reply to comment #2) > Try adding these two lines to /lib/systemd/system/syslog.socket: > > Conflicts=shutdown.target > Before=shutdown.target > > (as in > http://cgit.freedesktop.org/systemd/systemd/commit/?id=ead51eb4ed55981f290e40a871ffbca6480c4cd3) I did this, then ran "systemctl daemon-reload" before rebooting, and it worked the first time, but not any more. Now it hangs during shutdown as before.
(In reply to comment #7) > > When running Rawhide, I definitely recommend having SysRq enabled for the > > Alt+SysRq + {S,U,B} emergency combination. > > This is new to me > A pointer? Ahem! https://www.kernel.org/doc/Documentation/sysrq.txt https://fedoraproject.org/wiki/QA/Sysrq https://en.wikipedia.org/wiki/Magic_SysRq_key If Wikipedia has an article about it then it cannot be that new. :-)
Trust me, we had no pc's at school, many still don't. I'm almost middle-aged and on catch-up. :)
(In reply to comment #8) > I did this, then ran "systemctl daemon-reload" before rebooting, and it worked > the first time, but not any more. Now it hangs during shutdown as before. I reverted the edit, then hard powered off, then did the edit and systemctl daemon-reload command again and rebooted, and it seems to work persistently this time. Only difference is that I rebooted rather than powering off after originally making the changes (normally I poweroff each day). I don't see anything in the systemctl man page indicating that should make a difference. I'm sure the original edit was correct, since as I said it worked the first time, and the edit itself was persistent (though not its effect).
Sorry, meant to say that I powered off after making the original changes (which only worked once). This time, I rebooted instead.
Same problem with systemd-38-4.fc17, same fix works (comment 2 and comment 3).
Fixed in systemd-38-6.git9fa2f41.fc17.