From owner-freebsd-rc@FreeBSD.ORG Fri Dec 2 05:32:07 2011 Return-Path: Delivered-To: freebsd-rc@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 2A4A0106564A; Fri, 2 Dec 2011 05:32:07 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 929EB154314; Fri, 2 Dec 2011 05:32:06 +0000 (UTC) Message-ID: <4ED862D6.9090807@FreeBSD.org> Date: Thu, 01 Dec 2011 21:32:06 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:8.0) Gecko/20111110 Thunderbird/8.0 MIME-Version: 1.0 To: Devin Teske References: <039201ccb0ab$b3db9470$1b92bd50$@fisglobal.com> In-Reply-To: <039201ccb0ab$b3db9470$1b92bd50$@fisglobal.com> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@freebsd.org, Ken Smith , Parker-Smith , phk@freebsd.org, 'Julian Elischer' , Dave@FreeBSD.ORG Subject: Re: mount(8) bug? rc.d/mountlate bug? bug in both? X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 05:32:07 -0000 Short answer, tag the mount(s) noauto in fstab, and mount them in /etc/rc.local. More detailed analysis of your situation follows. On 12/01/2011 20:34, Devin Teske wrote: > Hi -RC@, Julian, Poul, and Ken, > > We need your help on FreeBSD-8.1! > > Please read the following dossier on our issue with simply attempting to add a > single NFS mount to fstab(5) ***without*** the side-effect of rebooting into > single-user mode should that mount fail for ANY reason during boot. > > FULL-DISCLOSURE: We've already tried marking the filesystem as "late" and/or > "bg" to no avail. We've traced the problem down to a possible bug in either > mount(8) or the `/etc/rc.d/mountlate' boot-script. Need confirmation that this > is a bug, OR a work-around to eliminate the numerous edge-cases where we can > reliably cause the system to boot into single-user mode. I don't think it's a bug in either. > Corollary: > > Having a workstation 3000+ miles away in India reboot into single-user mode > simply because of a momentary network hiccup (or any other situation that could > cause failure of the NFS mount) at boot is what we're trying to avoid. That is > to explain, avoiding the situation where a system that is physically afar from > becoming permanently unresponsive, requiring significant expenditure/effort to > rectify. If you're administrating a remote system it's reasonable to assume that you have a serial console on it. That said, we're certainly not *trying* to break stuff willy-nilly. > Possible Bug: > > As the system is booting, /etc/rc.d/mountcritremote attempts to mount the > filesystem. It fails. This is OK (because mountcritremote does not return > FAILURE status -- he returns SUCCESS and boot proceeds as-expected). > > Later, /etc/rc.d/mountlate runs and attempts to mount it again. It fails again > except this time mountlate calls "stop_boot" after the failure (dropping us to > single-user mode). This the expected/desired behavior. > The "possible bug" comes into play in reading /etc/rc.d/mountlate and finding > out just how exactly it determines that it should have been mounting this > filesystem in the first place. > > mountlate calls "/sbin/mount -d -a -l" to determine if there are any "late" > filesystems to mount. No. The -a in there means that it's looking for *all* unmounted file systems, including those marked "late." In fact a key reason for the division between mountcritremote and mountlate is that circumstances on the system may have changed to allow things that failed the first time to be mounted, *in addition to* specifically marking certain entries "late" because we know that they cannot succeed until later in the boot. > The filesystem is NOT marked as "late", but "/sbin/mount -d -a -l" will still > report it because it's not yet mounted. Right-O. > This is where we need to read mount(8) to learn that "-l" doesn't mean it will > report-on ONLY late-filesystems, but rather ALSO report-on late-filesystems. ... "When used in conjunction with the -a option ..." It's the -a bit that's important here. >>From mount(8): > > -l When used in conjunction with -a option, also mount those > file systems which are marked as ``late''. -- "We could put the whole Internet into a book." "Too practical." Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/