From owner-freebsd-stable@FreeBSD.ORG Fri Oct 3 21:56:07 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3BA5AF79; Fri, 3 Oct 2014 21:56:07 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F4115C60; Fri, 3 Oct 2014 21:56:06 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id DCC6C359DCD; Fri, 3 Oct 2014 23:56:03 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id CD09528494; Fri, 3 Oct 2014 23:56:03 +0200 (CEST) Date: Fri, 3 Oct 2014 23:56:03 +0200 From: Jilles Tjoelker To: Yamagi Burmeister Subject: Re: shutdown(8) not working after upgrade to 10.1-BETA3 Message-ID: <20141003215603.GA66579@stack.nl> References: <20141001171453.0e0f6ecad8769bd9a06b9425@yamagi.org> <20141002152929.6fc7d8303aa2b048ee6d686d@yamagi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141002152929.6fc7d8303aa2b048ee6d686d@yamagi.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: marcel@FreeBSD.org, freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 21:56:07 -0000 On Thu, Oct 02, 2014 at 03:29:29PM +0200, Yamagi Burmeister wrote: > On Wed, 1 Oct 2014 17:14:53 +0200 > Yamagi Burmeister wrote: > > Hello, > > I've updated my system from 10.0-RELEASE to 10.1-BETA3. The exakt > > version is: > > FreeBSD happy.home.yamagi.org 10.1-BETA3 FreeBSD 10.1-BETA3 #0 r272260: > > Sun Sep 28 19:35:56 CEST 2014 > > root@happy.home.yamagi.org:/usr/obj/usr/src/sys/GENERIC amd64 > > For some strange reasons shutdown(8) is no longer working for me. I > > type "shutdown -p now" into a virtual console. getty(8) exists on > > that console, but stays alive on any other consoles. After that nothing > > happens, the system continues to run like nothing ever happened. I'm > > able to login into another virtual console or via SSH, can start X.org > > and continue with my work. > > In contrast to that "halt -p" is working fine. The system shuts down > > immediately and the power is turned off. > > After typing "shutdown -p now" (while the shutdown process is hanging) > > "procstat -k 1" gives: > > 1 100002 init - mi_switch sleepq_catch_signals sleepq_wait_sig > > _cv_wait_sig ttydev_leave ttydev_close devfs_close VOP_CLOSE_APV vgonel > > vgone devfs_revoke VOP_REVOKE_APV sys_revoke amd64_syscall Xfast_syscall > > Looks to me that init(8) waits on a some tty to close. Which apparently > > never happens. A similar case was reported here: > > http://lists.freebsd.org/pipermail/freebsd-stable/2014-July/079159.html > > I wonder if I'm the only one seeing this. If necessary further data can > > be provided. > Okay, some more data points. As suggest in the thread linked below I've > tried to revert r261997 (MFC of r259441) and *tada* shutdown(8) is > working again. I think I'm hitting the issue discussed here: > http://lists.freebsd.org/pipermail/svn-src-all/2014-February/080880.html > CCing marcel@ as the author of r259441 and jilles@ who brought up the > problem. The problem I reported is that a thread may start spinning instead of interrupting a pending close or revoke when a signal is received. This is not the case here. Pid 1 is not spinning but simply sleeping, and it tends not to receive signals at this point. The problem here seems to be that the current definition of revoke(), which involves calling the device close function, is not suitable for calling from pid 1, since pid 1 should not wait indefinitely for tty output to drain. In fact, apart from one month in 1997 (SVN r27197-r27941), pid 1 only started calling revoke() in June 2009 (SVN r194198). Traditionally, only init's child processes called revoke(). A dirty workaround could be to fork a process to perform these revoke() calls. Note that because of r259441, this process cannot use signals to limit how long it blocks, so pid 1 must not wait indefinitely for the process to terminate. -- Jilles Tjoelker