Date: Sat, 31 Dec 2011 16:34:26 +0000 From: Chris Rees <crees@freebsd.org> To: Devin Teske <devin.teske@fisglobal.com> Cc: dougb@freebsd.org, freebsd-rc@freebsd.org Subject: Re: conf/163727: [rc.d] [patch] The mountlate rc.d boot script cannot be disabled Message-ID: <CADLo83-689nrvHUHAZenfRWoUq6S9CCFP28yWDavzp-_nV_jtw@mail.gmail.com> In-Reply-To: <8F16E728-1A94-4ECD-9D83-4A854AD7A702@fisglobal.com> References: <201112310758.pBV7webJ074390@freefall.freebsd.org> <8F16E728-1A94-4ECD-9D83-4A854AD7A702@fisglobal.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 31 December 2011 16:08, Devin Teske <devin.teske@fisglobal.com> wrote: > > On Dec 30, 2011, at 11:58 PM, <dougb@FreeBSD.org> wrote: > >> Old Synopsis: [rc.d] [patch] The mountlate RCNG boot script cannot be di= sabled >> New Synopsis: [rc.d] [patch] The mountlate rc.d boot script cannot be di= sabled >> >> State-Changed-From-To: open->closed > > Should I take this one to the forums to get a wider consensus? > > Because everybody in the community I talk to agrees with me -- in the sen= se that mountlate should be abled to be disabled for those that desire-to. > > >> State-Changed-By: dougb >> State-Changed-When: Sat Dec 31 07:54:00 UTC 2011 >> State-Changed-Why: >> >> 1. What you're talking about is an extreme edge case. > > I completely disagree. > > About 10 years ago, our company paid into the FreeBSD community tens-of-t= housands of dollars to make certain that NFS was both rock-stable and could= be used as a production platform. > > Now, we're seeing that NFS is a second-class citizen (only that it is cur= rently _impossible_ without modification of the FreeBSD system to have even= one single NFS mount in your fstab(5) without risking certain eventual dea= th for, being dropped into single-user mode). > > The fact of the matter is that we use NFS to "band" our BSD systems toget= her and without any modification to the FreeBSD system, we've identified no= less than a half-dozen cases (that are _not_ extreme in any way) where the= system boots into single-user mode. > > But then again, I'm sure that you'll tell me that a simple power-outage i= s "extreme" -- in which case, even a power-outage can cause several hundred= s of machines to boot into single-user mode simply because there was a race= -condition between which machines would have DNS, which machines would have= their "companion PC's" boot just a smidge slower than the machines that mo= unt-them. > > > >> If you can't figure >> out how to properly configure these systems, > > We're resorting to insults now? Gee, thanks! > > > >> then simply removing the script >> from /etc/rc.d is enough. > > You reject my patch and tell me to "simply remov[e] the script". This con= fuses me. I would have in all earnest thought this was not a possible outco= me. But hey... I guess that (removing the script) works too, just hadn't th= ought of it. > > I'd still rather see the community embrace this simple patch. After-all, = what's the harm if some administrator wants to disable this script? Like yo= u say... deleting the script works too. But,... after deletion one cannot j= ust "simply change his mind" ... as he now has to scp the script out from a= nother box (which hopefully there's a copy lying around somewhere). > > I think making the script toggle-able is better than just killing it (whi= ch is dirty as it leavers no easy way to turn it back on; in a general sens= e). > > > >> >> 2. Don't attempt to mount critical remote file systems using DNS names. > > It doesn't matter if you use DNS names or not. If you don't use DNS names= , then the box can still drop to single-user mode if the destination is not= mountable. This can occur for example in a power-outage and the machines a= re not brought up in the right order or there is a momentary lapse caused b= y different boot-speeds of different hardware. > > Trust me doug, we've been battling these cases for months. > > The tiny two-line patch that is required to make mountlate toggle-able se= ems to be the "least evil" -- that is, including comparison to "simply remo= ving the script" which in itself seems evil. > > > >> This >> has been true for as long as I can remember. > > That may be so, but we at VICOR have the distinct impression that somewhe= re along the line between FreeBSD-4 (where we were extremely active -- host= ing FreeBSD release parties at our office, contributing daily both monetari= ly and code-wise back when 3 committers were actively employed here) and -C= URRENT, that NFS was made a "second-class citizen". > > Back in the FreeBSD-4 days, we would have never imagined EVER making NFS = critical to boot into single-user mode, because we know that NFS fails all = the time and furthermore, we expect to SSH in and execute "mount -a" to fix= the problem. > > Mind you, I do see that there are a LOT of mechanisms for indicating via = configuration that some network filesystem ought not to be critical to boot= ing into multi-user mode, but in practice, not a damned one of them works. = I've raised patches to fix "bg", I've raised patches to fix "late", and I'v= e even suggested now that the "mountlate" mechanism be able to be disabled = if-so-desired. > > The net-effect to all of this, is that we feel that the community is acti= vely trying to prevent progress-forward in finding a way to prevent a netwo= rk filesystem from hanging the boot process, and we can't figure out WHY!!?= ? > > It's feeling like it's time to take this one to the forums. > > > >> >> 3. If you have critical remote systems that you can't afford to have han= g >> in single user mode, put a serial console on them. > > That's tantamount to a mandate to force our customers to build-out infras= tructure that they currently (a) do not have and (b) do not desire. > > Furthermore, we can't force our customers to do anything. If they say "no= " to serial consoles, we can't force them. > > That puts us in the unfortunate circumstance where we employ a field engi= neer that could gladly fix the problem remotely at 2AM via logging into ssh= d running in multi-user mode but alas... the system is stuck in single-user= mode so the field engineer has to be dispatched at 2AM to go type a couple= commands (which seems ridiculous). > > > >> >> Meta-notes: >> >> 1. I obeyed your disclaimer text > > I can't send e-mail without that being appended. I suggest you simply ign= ore it (the e-mail was directly addressed to the Gnats system and therefore= the contents were _meant_ to be digested). > > > >> and removed the second patch that you sent. >> >> 2. It hasn't been "rcng" for a long time now. The preferred term is rc.d= . > > Thanks. > > >> >> >> Responsible-Changed-From-To: freebsd-rc->dougb >> Responsible-Changed-By: dougb >> Responsible-Changed-When: Sat Dec 31 07:54:00 UTC 2011 >> Responsible-Changed-Why: >> >> I'm closing this. > > Don't be surprised if it gets re-submitted. > Re-submitting won't help your cause. However... I do think you have a slight bit of a point-- Doug, is there a reason that the patch is harmful? Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83-689nrvHUHAZenfRWoUq6S9CCFP28yWDavzp-_nV_jtw>