Date: Mon, 10 Jul 2000 21:45:43 -0500 (CDT) From: Mike Meyer <mwm@mired.org> To: "Daniel C. Sobral" <dcs@newsguy.com> Cc: Mike Meyer <mwm@mired.org>, clefevre@citeweb.net, freebsd-current@FreeBSD.ORG Subject: Re: etc/rc.d & things... Message-ID: <14698.35415.557998.369712@guru.mired.org> In-Reply-To: <3969D84A.D23A84B6@newsguy.com> References: <bulk.42172.20000708033413@hub.freebsd.org> <14695.51428.314772.426883@guru.mired.org> <itufx9ug.fsf@pc166.gits.fr> <14697.31325.422020.803101@guru.mired.org> <3969D84A.D23A84B6@newsguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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, <mike P.S. - anyone else remember rc.single? Anyone care? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14698.35415.557998.369712>