Date: Sat, 4 Oct 2014 10:05:24 +0200 From: Yamagi Burmeister <lists@yamagi.org> To: freebsd-stable@freebsd.org Cc: marcel@FreeBSD.org, jilles@stack.nl 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 3 Oct 2014 23:56:03 +0200 Jilles Tjoelker <jilles@stack.nl> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141004100524.de6d2b60708d0e95c6f1b0a9>