From owner-freebsd-current Mon Jul 10 19:46:30 2000 Delivered-To: freebsd-current@freebsd.org Received: from guru.mired.org (zoom1-233.telepath.com [216.14.1.233]) by hub.freebsd.org (Postfix) with SMTP id 75A2037B55B for ; Mon, 10 Jul 2000 19:46:21 -0700 (PDT) (envelope-from mwm@mired.org) Received: (qmail 52885 invoked by uid 100); 11 Jul 2000 02:45:43 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14698.35415.557998.369712@guru.mired.org> Date: Mon, 10 Jul 2000 21:45:43 -0500 (CDT) To: "Daniel C. Sobral" Cc: Mike Meyer , clefevre@citeweb.net, freebsd-current@FreeBSD.ORG Subject: Re: etc/rc.d & things... In-Reply-To: <3969D84A.D23A84B6@newsguy.com> References: <14695.51428.314772.426883@guru.mired.org> <14697.31325.422020.803101@guru.mired.org> <3969D84A.D23A84B6@newsguy.com> X-Mailer: VM 6.72 under 21.1 (patch 10) "Capitol Reef" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Daniel C. Sobral writes: > Mike Meyer wrote: > The multiple levels are there to deal with changes in state. In BSD, for > instance, we have single user/multi-user. A number of other variations > can exist, both in heavy duty servers where you might want to bring > certain services down for upgrade and then back up, and "desktop" > machines, such as notebooks where you can be stand-alone, docked into > different networks (eg. home/work). I'm familiar with why mutliple levels exist. I've never run into a system that had a real use for more than three run levels - powered off, maintenance, and up - though I've not dealt with notebooks. Needing to shut down some services in the up mode, or start some in the maintenance mode, is why having "start" and "stop" arguments to the scripts in rc.d is nice. If you find yourself needing to change to the state on a fixed bag of servers regularly, that feature on the scripts allows any admin worth hiring to write scripts to go back and forth easier than they can configure the SysV run levels. This doesn't work very well for the notebook example, though. > Thing is, SysV does it in a very ugly way, and not flexible enough > either. The functionality SysV provides isn't nearly worth the complexity. That was why I decided not to bother with it. Supporting multiple run levels adds lots of complexity. Tools to change run levels, hooks into init, etc. Possibly a simpler system - "run states" - which aren't layered like the SysV run levels would provide most of the functionality without anywhere near the complexity. The state transitions are all from single-user (where rc.shutdown takes you) to and from different up states, using different pairs of directories to rc the system. In this case, the K* and S* filenames make more sense, so there's only one directory per state. This would handle the notebook, and anything that required some set of services to be turned on from single-user mode for maintenance. > and my favorite substitute proposal: > > http://www.roguetrader.com/~brandon/sas/. Having working code makes it a lot more attractive than any of the others - or what we've discussed here. It's also a lot more complex that what we've been discussing. If you're willing to work on getting this integrated into the core, cool. If not - then I'd still like to see something that is easier to configure and deals with startup/shutdown issues better. Thanx,