From owner-freebsd-questions@FreeBSD.ORG Sat Jul 5 15:16:46 2014 Return-Path: Delivered-To: questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5772838 for ; Sat, 5 Jul 2014 15:16:46 +0000 (UTC) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 812D322D4 for ; Sat, 5 Jul 2014 15:16:46 +0000 (UTC) Received: (from brett@localhost) by mail.lariat.net (8.9.3/8.9.3) id IAA08661 for questions@freebsd.org; Sat, 5 Jul 2014 08:38:38 -0600 (MDT) Date: Sat, 5 Jul 2014 08:38:38 -0600 (MDT) From: Brett Glass Message-Id: <201407051438.IAA08661@mail.lariat.net> To: questions@freebsd.org Subject: Unusual console hangup X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 15:16:46 -0000 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