Unusual console hangup

Brett Glass brett at lariat.net
Sat Jul 5 15:16:46 UTC 2014


On one of our servers, which is running the latest patch level of FreeBSD
10.0-RELEASE, an odd thing happened. I was using the VGA console, via a USB
keyboard, to do some maintenance when the virtual terminal locked up. I was
pinging a remote host and hit ^C; instead of coming back to the login prompt
the vty froze and became unresponsive to keystrokes. Hitting Alt-F2, Alt-F3,
etc. took me to other vtys that were still working.

I tried to get the virtual terminal working again by killing the processes
associated with it; this didn't work. I then tried sending a hangup signal to
the init process; no luck. I even edited /etc/ttys temporarily, turning the
virtual terminal off. I then sent a hangup to init, turned the virtual
terminal back on, and sent another hangup to init. Nothing brought it back to
life.

The only thing I could figure was that there was a glitch in the console
driver, and I didn't have time for any more experimentation, so I simply went
on with my work using another virtual terminal. I finished my maintenance and
scheduled a reboot for the middle of the night.

I was awakened in the early morning by a user complaining that the server
wasn't working. While the machine was pingable, I couldn't log in remotely;
the ssh process was dead. When I went back to the actual console, I found that
the scheduled middle-of-the-night reboot (echo shutdown -r now | at 0300) did
kill all daemons, locking me out, but then did not reboot the system! The
wedged driver had apparently stopped it from doing so.

To sum up: there may be a bug in the recently revised console driver that can
cause the vty (which is implemented in a kernel driver, so it can't just be
restarted as a user process can) to lock up. When it does, the system can't be
shut down and rebooted in an orderly fashion. Has anyone else seen this? I
can't find a PR that directly mentions it.

--Brett Glass


More information about the freebsd-questions mailing list