Date: Thu, 24 Apr 1997 02:18:03 -0400 From: "Kevin P. Neal" <kpneal@pobox.com> To: Chris Csanady <ccsanady@nyx.pr.mcs.net> Cc: hackers@freebsd.org Subject: Re: Discussion of boot mechanism (Was Re: /etc/netstart bogons.. ) Message-ID: <1.5.4.32.19970424061803.017959d4@mindspring.com>
next in thread | raw e-mail | index | archive | help
At 11:06 PM 4/23/97 -0500, Chris Csanady wrote: > >> >>On Wed, 23 Apr 1997, Brian Somers wrote: >> >>> I like the idea of a "summary" at the top of /etc/rc (oh, and >>> netstart should be rc.net as someone mentioned a while ago): >> >>That was me. I was just about ready to say "I'm changing netstart to >>rc.net unless someone stops me", but I guess the change might come with >>this sweep, unless rc.d takes over. >I'll try to go over a few issues that I see, and hopefully we can have a >sane discussion about this. :) > >1. run levels, and lame shell script links like S01*, S10*, etc. There is >basically no need for this--it is essentially a hack to get around > the lack of a real dependancy handling system. How best to implement it > though? Even some people have proposed using make. I dont know if this > could support the kind of dynamic dependancies we want though. I was > thinking more along the lines of having something like > "#require NETWORK" at the beginning of the scripts, and using a generic > sh script to parse / order / record dependancy information. I thought about this also. How about having "classes" of scripts, with specific names on individual scripts as well. This would allow you to do things like having, for example, Apache not start up until after the Networking stuff has started. Also, have some Networking programs not start until named has started, etc. Have named not start until ifconfig runs, etc. Some scripts are going to fail for somebody sometime. In these cases should you drop back down to the level you are leaving, or continue on up? As for run levels, why not define three: halted, single user, and multiuser. Have the multiuser level be configurable (if you want it at, say, 3 then you can have it be 3). Have the other levels be user configurable. > Also, the scripts echo's and such may be ordered by the dependancy > graph somehow and grouped so that we'd have something nicer to look at > than "The system is coming up." or some unorganized mess. :) Well, if you don't want to see messages, it'd be spiffy if you could cut them off. I kinda like the way AIX prints out stuff on boot: Starting the NIS service... The NIS service has started. etc. Something like this would allow you to define services, and have a generic tool for starting and stopping them. I know at work I'd really like to have an easy way to say "start all web servers", other than cobbling together start_server and stop_server scripts that only I use (because only I use xterm+bash instead of Jterm+ksh). Plus, a generic mechanism would make training easier for when you need to train some guy in a datacenter to start and stop services late-as-heck at night when you yourself don't want to be paged. (you'd be surprised (maybe not) how difficult it is to teach some datacenter person to cd /local/etc/httpd.dir ; stop_server ; start_server). >2. What about location, ie. do we want to keep all local changes in > /usr/local/etc or some such place not on the root. Regardless, I think > that the dependancy system should work across the directories. True. >3. Also, if we are to have a true dependancy system, some state will have > to be kept somewhere in order to keep track of whats running and how > to undo it upon system (or individual package) shutdown. Where do we > put this? /var may not be mounted, and it would be nice to keep / ro. > As well as recording what is started and stopped, we'd also need > a default list of packages to start--perhaps in /etc/config. As well has keeping rc-style startup for the people that just *like* it. I'd like to see the startup scripts get run not by init, but by a program run by init. This would allow for very easy additions of other rc.d directories. I sure do wish Digital UNIX had this, it'd save me from having to hack scripts together to do the same job. *sigh* Like, where I work we have stuff in /local/etc/rc.d/* (which is a different disk than /, so servers can be swapped around fairly easily). An easy way of doing this on *BSD would be nice. >Whatever we come up with, it would also be nice to have standard across the >BSD's if possible. I know that this issue keeps popping up, but I think >thats only because it needs to be adressed someday. I hope I am not deeply >upsetting anyone. :) Just get the holy water ready in case of war. -- XCOMM Kevin P. Neal, Junior, Comp. Sci. - House of Retrocomputing XCOMM mailto:kpneal@pobox.com - http://www.pobox.com/~kpn/ XCOMM kpneal@eos.ncsu.edu Spoken by Keir Finlow-Bates: XCOMM "Good grief, I've just noticed I've typed in a rant. Sorry chaps!"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1.5.4.32.19970424061803.017959d4>