Date: Thu, 01 Dec 2011 21:32:06 -0800 From: Doug Barton <dougb@FreeBSD.org> To: Devin Teske <devin.teske@fisglobal.com> Cc: freebsd-rc@freebsd.org, Ken Smith <kensmith@buffalo.edu>, Parker-Smith <daveps@vicor.com>, phk@freebsd.org, 'Julian Elischer' <julian@freebsd.org>, Dave@FreeBSD.ORG Subject: Re: mount(8) bug? rc.d/mountlate bug? bug in both? Message-ID: <4ED862D6.9090807@FreeBSD.org> In-Reply-To: <039201ccb0ab$b3db9470$1b92bd50$@fisglobal.com> References: <039201ccb0ab$b3db9470$1b92bd50$@fisglobal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ED862D6.9090807>