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. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=163727 -- Devin _____________ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-rc To unsubscribe, send any mail to "[email protected]"
