Description of problem: Running the command "init 1" (as root) from a terminal session running in the LXDE graphical environment causes the computer to freeze/hang/lock-up. Version-Release number of selected component (if applicable): systemd-37-3.fc16.x86_64 How reproducible: Every time I've tried it, I think. Steps to Reproduce: 1. Login to system. 2. Open a terminal window. 3. Become 'root' and then execute the command "init 1". Actual results: Screen goes black, and becomes totally unresponsive. Expected results: I expected the system to gracefully transition to run-level "1" and to have a working console/terminal session. Additional info:
Does SysRq still work? Make sure it is enabled before reproducing the hang: echo "1" > /proc/sys/kernel/sysrq Then see if Alt+SysRq+B reboots the machine from the unresponsive state.
Yes, Alt+SysRq+B was able to reboot the system.
I'm able to reproduce this in a VM. When it happens, rescue.service (and bash within it) seems to be running as expected, but the console is in a weird state. My first suspect was plymouth, but I can reproduce this even with all plymouth units masked. As a workaround it helps if in /lib/systemd/system/rescue.service I replace: StandardInput=tty-force with StandardInput=tty A different effective workaround was to insert a oneshot service doing "/bin/sleep 3" before rescue.service. It seems that the forced TIOCSCTTY confuses the console if it's done too soon after killing the X server. I don't understand this console stuff.
CC'ing some people who may be able to comment more on the console/X interactions.
It's possible that rescue.service/start runs in parallel with prefdm.service/stop. So the TIOCSCTTY on /dev/console may be called before the X server has exited.
(In reply to comment #5) > It's possible that rescue.service/start runs in parallel with > prefdm.service/stop. systemd debug log shows that this is the case. It also shows that Xorg ends with a SIGSEGV. The end of /var/log/Xorg.0.log has: [ 39.799] (II) evdev: Power Button: Close [ 39.800] (II) UnloadModule: "evdev" [ 39.800] (II) Unloading evdev [ 39.839] (II) evdev: QEMU 0.15.1 QEMU USB Tablet: Close [ 39.839] (II) UnloadModule: "evdev" [ 39.839] (II) Unloading evdev [ 39.872] (II) evdev: AT Translated Set 2 keyboard: Close [ 39.872] (II) UnloadModule: "evdev" [ 39.872] (II) Unloading evdev [ 39.872] (II) VMWARE(0): VMMOUSE DEVICE_OFF/CLOSE [ 39.980] (II) VMWARE(0): VMMOUSE DEVICE_OFF/CLOSE [ 40.280] (II) VMWARE(0): VMMouseUnInit [ 40.632] (WW) xf86CloseConsole: KDSETMODE failed: Input/output error [ 40.633] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error [ 40.633] Fatal server error: [ 40.633] xf86CloseConsole: VT_ACTIVATE failed: Input/output error [ 40.633] [ 40.633] Please consult the Fedora Project support at http://wiki.x.org for help. [ 40.633] Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 40.633] [ 40.633] Backtrace: There's no backtrace. Bug 688658 looks similar.
Using 'tty-force' steals the terminal from Xorg, so Xorg cannot set the terminal back to its original settings on exit. The terminal stays in graphics mode and raw keyboard mode. It would be possible to add ordering to make sure prefdm.service exits before rescue.service starts, but as there could be other cases where the console is in an unexpected mode, systemd should just improve its resetting. Upstream commits: http://cgit.freedesktop.org/systemd/commit/?id=df465b3f4419b6ba2e12bf9a5f7d7bde5a0c3531 http://cgit.freedesktop.org/systemd/commit/?id=5c0100a53772eb7f4b11db7b071fc63e82e5a1a7
systemd-37-6.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/systemd-37-6.fc16
Package systemd-37-6.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-6.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-6.fc16 then log in and leave karma (feedback).
# yum update ... gets everything else up-to-date # yum --enablerepo=updates-testing systemd ... updates systemd, systemd, systemd-units, and systemd-sysv packages to 37-6 Reboot. Test. Problem fixed. Thank you!
Package systemd-37-7.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-7.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-7.fc16 then log in and leave karma (feedback).
Package systemd-37-8.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-8.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-8.fc16 then log in and leave karma (feedback).
Package systemd-37-10.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-10.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-10.fc16 then log in and leave karma (feedback).
Package systemd-37-11.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing systemd-37-11.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-0409/systemd-37-11.fc16 then log in and leave karma (feedback).
systemd-37-11.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.