On 31 December 2011 16:08, Devin Teske <[email protected]> wrote: > > On Dec 30, 2011, at 11:58 PM, <[email protected]> wrote: > >> Old Synopsis: [rc.d] [patch] The mountlate RCNG boot script cannot be >> disabled >> New Synopsis: [rc.d] [patch] The mountlate rc.d boot script cannot be >> disabled >> >> 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: >> >> 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-thousands 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 > currently _impossible_ without modification of the FreeBSD system to have > even one 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 together > 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 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-condition between which machines would have DNS, which machines would > have their "companion PC's" boot just a smidge slower than the machines that > mount-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 > confuses 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 > thought 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 you > say... deleting the script works too. But,... after deletion one cannot just > "simply change his mind" ... as he now has to scp the script out from another > 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). > > > >> >> 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 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 seems > to be the "least evil" -- that is, including comparison to "simply removing > 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 somewhere > along the line between FreeBSD-4 (where we were extremely active -- hosting > FreeBSD release parties at our office, contributing daily both monetarily and > code-wise back when 3 committers were actively employed here) and -CURRENT, > 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 > booting 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 actively > 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. > > > >> >> 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 > infrastructure 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 engineer > 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 > 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 ignore > 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "[email protected]"
