From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 08:05:36 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 95F1B813; Sat, 4 Oct 2014 08:05:36 +0000 (UTC) Received: from mail1.yamagi.org (yugo.yamagi.org [212.48.122.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 57E02E4; Sat, 4 Oct 2014 08:05:35 +0000 (UTC) Received: from p579a631c.dip0.t-ipconnect.de ([87.154.99.28] helo=happy.home.yamagi.org) by mail1.yamagi.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82_1-5b7a7c0-XX (FreeBSD)) (envelope-from ) id 1XaKLK-0009Hx-Ff; Sat, 04 Oct 2014 10:05:32 +0200 Date: Sat, 4 Oct 2014 10:05:24 +0200 From: Yamagi Burmeister To: freebsd-stable@freebsd.org Subject: Re: shutdown(8) not working after upgrade to 10.1-BETA3 Message-Id: <20141004100524.de6d2b60708d0e95c6f1b0a9@yamagi.org> In-Reply-To: <20141003215603.GA66579@stack.nl> References: <20141001171453.0e0f6ecad8769bd9a06b9425@yamagi.org> <20141002152929.6fc7d8303aa2b048ee6d686d@yamagi.org> <20141003215603.GA66579@stack.nl> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd10.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: marcel@FreeBSD.org, jilles@stack.nl 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: Sat, 04 Oct 2014 08:05:36 -0000 On Fri, 3 Oct 2014 23:56:03 +0200 Jilles Tjoelker wrote: > 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. Okay, I didn't realize that. > 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. That sounds rather hacky. But at a very first glance I don't see a better solution, too. Thank you, Yamagi -- Homepage: www.yamagi.org XMPP: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB