Red Hat Bugzilla – Bug 812571
systemctl reboot hangs when commanded from ssh session
Last modified: 2012-09-14 12:53:26 EDT
Description of problem:
When logged in a root through ssh and issuing:
the system hangs and does not reboot.
Version-Release number of selected component (if applicable):
I have tried this on three systems. It works fine on two of the systems and fails on one consistently.
Steps to Reproduce:
1. Log in as root using ssh
2. Issue systemctl reboot;exit commands
System hangs. I had to drive over 40 miles round trip to reboot the system.
The system locks up in some state. The hardware is still running, but it does not respond to the keyboard or mouse and no ports are open. Screen is black. Have to hold the power button for five seconds to get the system to power off. Then re-power to get to boot. Booting seems slow even if there is no fsck done, but after it boots, all seems well.
System should reboot.
This just started happening with the last few kernels. I think it started with kernel-PAE 3.3.1-2.fc16 but it may have been the one before that.
The system that fails is a Dell Precision 380 Workstation with Intel(R) Pentium(R) D CPU 3.00GHz.
One of the ones that reboots normally is also a Dell with a Intel(R) Pentium(R) 4 CPU 2.40GHz. The other one that reboots is a home built on an Asus motherboard using an AMD Athlon(tm) 64 Processor 3200+.
Is the fact, that the reboot is issued from an ssh session, actually important?
I mean, have you confirmed that reboot works fine from a local login?
Reboot works from menu on display manager (I use KDE).
Reboot works from system logout/shutdown/restart widget on toolbar in KDE.
Reboot works from a non-graphic terminal login (tty02) using systemctl reboot.
systemctl reboot hangs when run from a graphical session (kde) when run from an su - session.
systemctl reboot hangs when run from a ssh session when run from an su - session.
systemctl reboot hangs when run from a ssh session using root@host but did get to a point where at least the network was started.
Somewhere along the way, the system got into a start where the graphical system would not start and there were no tty terminal sessions running (ctl-alt-F2(3-6). I found that the network was running and from an ssh session saw that the /tmp/.X0-lock file existed, but the display manager was not running on the screen and the system did not respond to any keyboard actions. I did a systemctl poweroff from the ssh session. When I powered up, the display manager started properly.
When this happens, could you please log in via a second ssh session, then run "systemctl list-jobs", and attach the output here?
Also, could you run "pstack" on the reboot process to see where it is hanging? (also attach output here)
I hit the same issue on an upgraded F15 to F16 with an .i386 PAE kernel. a while back when a friend of mine had decided to upgrade his a Fedora xbmc media center and the upgrade process or specifically the Gnome part of the upgrading process left him ( more specifically his user account ) with none working ( wireless ) keyboard and no means to reboot the machine ( you got a hand it to those Gnome designers press a key to get reboot in the menu but what happens if you wind up not having any keyboard duh, idiots <sigh> ).
So I rebooted via ssh running the reboot command and it hang, waited for 20 minutes before performing hard reboot got the wireless keyboard working again in Gnome for his user account and tested rebooting locally which work just fine both from multi-user.target and within Gnome itself, then logged again to the machine via ssh and issued the command and it hang again.
Seem to be hanging on NetworkManager/SSH at that time...
Will try to get the "systemctl list-jobs" and "pstack" data this weekend. This server is in use by others and I try to keep it available during the week days.
Was not able to get list-jobs or pstack data this time. Will try again later.
I got the chance to reboot since a new kernel was pushed.
I opened two ssh sessions into the system. One for root and one for another user which was then su-ed to root. The sync;systemctl reboot was issued from the su root session.
Both ssh sessions were closed by the system.
The system hung on the way down I believe because it happens almost immediately. There is not any terminal available from the system console. Nothing is displayed and the monitor goes into power save mode which indicates there is no video signal.
The system would not allow a new ssh connection; the connection is refused.
The system does respond to ping.
The system did not shutdown. I waited 5 minutes. I had to do a hard power off by holding in the power button on the system.
The system booted normally after power was turned on again.
Do you use any more exotic low-level service, such as autofs or so?
This is no longer happening with the new kernel.
OK, closing then.