Date: Sat, 31 Dec 2011 08:08:03 -0800 From: Devin Teske <devin.teske@fisglobal.com> To: <dougb@FreeBSD.org> Cc: freebsd-rc@FreeBSD.org Subject: Re: conf/163727: [rc.d] [patch] The mountlate rc.d boot script cannot be disabled Message-ID: <8F16E728-1A94-4ECD-9D83-4A854AD7A702@fisglobal.com> In-Reply-To: <201112310758.pBV7webJ074390@freefall.freebsd.org> References: <201112310758.pBV7webJ074390@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Dec 30, 2011, at 11:58 PM, <dougb@FreeBSD.org> wrote: > Old Synopsis: [rc.d] [patch] The mountlate RCNG boot script cannot be dis= abled > New Synopsis: [rc.d] [patch] The mountlate rc.d boot script cannot be dis= abled >=20 > 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 sense= 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:=20 >=20 > 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-tho= usands of dollars to make certain that NFS was both rock-stable and could b= e used as a production platform. Now, we're seeing that NFS is a second-class citizen (only that it is curre= ntly _impossible_ without modification of the FreeBSD system to have even o= ne single NFS mount in your fstab(5) without risking certain eventual death= for, being dropped into single-user mode). The fact of the matter is that we use NFS to "band" our BSD systems togethe= r and without any modification to the FreeBSD system, we've identified no l= ess than a half-dozen cases (that are _not_ extreme in any way) where the s= ystem boots into single-user mode. But then again, I'm sure that you'll tell me that a simple power-outage is = "extreme" -- in which case, even a power-outage can cause several hundreds = of machines to boot into single-user mode simply because there was a race-c= ondition between which machines would have DNS, which machines would have t= heir "companion PC's" boot just a smidge slower than the machines that moun= t-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 confu= ses me. I would have in all earnest thought this was not a possible outcome= . But hey... I guess that (removing the script) works too, just hadn't thou= ght of it. I'd still rather see the community embrace this simple patch. After-all, wh= at's the harm if some administrator wants to disable this script? Like you = say... deleting the script works too. But,... after deletion one cannot jus= t "simply change his mind" ... as he now has to scp the script out from ano= ther box (which hopefully there's a copy lying around somewhere). I think making the script toggle-able is better than just killing it (which= is dirty as it leavers no easy way to turn it back on; in a general sense). >=20 > 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 m= ountable. This can occur for example in a power-outage and the machines are= not brought up in the right order or there is a momentary lapse caused by = 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 seem= s to be the "least evil" -- that is, including comparison to "simply removi= ng the script" which in itself seems evil. > This > has been true for as long as I can remember.=20 That may be so, but we at VICOR have the distinct impression that somewhere= along the line between FreeBSD-4 (where we were extremely active -- hostin= g FreeBSD release parties at our office, contributing daily both monetarily= and code-wise back when 3 committers were actively employed here) and -CUR= RENT, that NFS was made a "second-class citizen". Back in the FreeBSD-4 days, we would have never imagined EVER making NFS cr= itical to boot into single-user mode, because we know that NFS fails all th= e time and furthermore, we expect to SSH in and execute "mount -a" to fix t= he problem. Mind you, I do see that there are a LOT of mechanisms for indicating via co= nfiguration that some network filesystem ought not to be critical to bootin= g 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've = 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 active= ly trying to prevent progress-forward in finding a way to prevent a network= 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. >=20 > 3. If you have critical remote systems that you can't afford to have hang > in single user mode, put a serial console on them. That's tantamount to a mandate to force our customers to build-out infrastr= ucture 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 engine= er that could gladly fix the problem remotely at 2AM via logging into sshd = running in multi-user mode but alas... the system is stuck in single-user m= ode so the field engineer has to be dispatched at 2AM to go type a couple c= ommands (which seems ridiculous). >=20 > Meta-notes: >=20 > 1. I obeyed your disclaimer text I can't send e-mail without that being appended. I suggest you simply ignor= e it (the e-mail was directly addressed to the Gnats system and therefore t= he contents were _meant_ to be digested). > and removed the second patch that you sent. >=20 > 2. It hasn't been "rcng" for a long time now. The preferred term is rc.d. Thanks. >=20 >=20 > 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:=20 >=20 > I'm closing this. Don't be surprised if it gets re-submitted. >=20 > http://www.freebsd.org/cgi/query-pr.cgi?pr=3D163727 --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8F16E728-1A94-4ECD-9D83-4A854AD7A702>