Date: Sun, 27 Apr 1997 23:50:29 -0400 From: "Kevin P. Neal" <kpneal@pobox.com> To: Chris Csanady <ccsanady@nyx.pr.mcs.net> Cc: patl@Phoenix.volant.org, Robert Withrow <witr@rwwa.com>, hackers@freebsd.org Subject: Re: /etc/netstart bogons.. Message-ID: <1.5.4.32.19970428035029.0089464c@mindspring.com>
next in thread | raw e-mail | index | archive | help
At 04:16 PM 4/27/97 -0500, Chris Csanady wrote: > >>> >>> ccsanady@nyx.pr.mcs.net said: >>> :- And the two-digit prefix? These are no more than a hack aimed at >>> :- solving the dependancy problem >>> >>> I've often tought about *that* part. I think that it would be better >>> if the individual rc scripts would provide *shell functions* to >>> start, stop, etc. It would also provide a declaration section that would >>> define which things the package *requires*. You could then tsort the >>> total list of dependencies (from an outer *control* script) and execute >>> the appropriate functions in the required order. >> >>Explain to me exactly how this would be -easier- to use. Exactly > >Having more functionalitly does not necessarily make things easier. In >fact, the startup mechanism is likely to be more involved, but this will >not impact the scripts themselves. If anything, it will be not be >easier, or harder, just different... > >>what steps would be taken to 1) manually start/stop/restart a service. >>2) Add a service to the restart sequence for multi-user. 3) Remove >>a service from the restart sequence for multi-user, but leave it >>available for manual start. 4) Find out the script execution order. > >1) I was wondering about this myself.. I really don't see how it would > change the basic idea if it was a script rather than a function > though. Why restrict startup scripts to just "scripts"? >2) Just add a script in the /etc/init.d directory.. > >3) What about having a single configuration file per state? Just a list > of the services to start included. I think a file is simpler than > a directory. ;-) These two are related. How about having new programs: register_svc -- These would put scripts for starting and stopping "services" unregister_svc -- inside some directory or database or whatever. mod_runstate -- Generic interface program. Used to add and remove services from a runstate. Also used to change the arguments used. When adding and removing services from a runstate, it will compute the ordering and dependencies (so they don't have to be recalculated at every boot). Save this data to a file or files in /etc (human readable in case of ... whatever). >4) This is a bit more difficult. How about providing an option to /etc/rc > to make it output what it *would* do if it was run? It then > internally handles the tsorting/etc and outputs the execution order. > This would require very little extra code.. > >I think it is obvious that at least a few things need to be worked out. >That shouldn't stop us though, right? :-) Cool. A "mod_runstate" program, since it generates the startup/shutdown info when a service is added, could trivially be amended to print out what it *would* do on boot. Heck, it could even generate a flat file that does all of the magic, if you *really* like the old way. Imagine having the traditional rc scripts be generated by some automatic method. >>As far as I can tell, the only win is the automatic dependency >>sorting; and I can easily imagine ports or packages missing a > >This is a large win imho... > >>dependency update. The sequenced symlinks certainly aren't >>perfect; but they show the order at a glance; and by defining >>known sequence points it is easy for install scripts to insert >>a startup between the necessary levels. In practice, this is >>usually adequate to handle the dependencies. > >But this does *not* handle dependancies--only ordering. There is a >huge difference. If something fails, the outcome is unknown.. Already "solved", see above. >>> I *hate* the stupid ``run-levels'' symlink stuff. >> >>Don't let your prejudice against the symlinks or run-levels >>lead you into something even cruftier. > >*sigh* I think this will be the largest stumbling block. If we >can come up with an elegant way to handle true dependancies, and >multiple run states (not levels), would anyone really mind? Nah, it'd be pretty cool. I like the idea of naming, not numbering, the runstates. Less confusion. -- 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.19970428035029.0089464c>