Date: Sun, 27 Apr 1997 16:16:20 -0500 From: Chris Csanady <ccsanady@nyx.pr.mcs.net> To: patl@Phoenix.volant.org Cc: Robert Withrow <witr@rwwa.com>, hackers@freebsd.org Subject: Re: /etc/netstart bogons.. Message-ID: <199704272116.QAA11062@nyx.pr.mcs.net> In-Reply-To: Your message of Sun, 27 Apr 1997 10:59:03 -0700. <ML-3.3.862163943.3010.patl@asimov>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >> 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. 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. ;-) 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? :-) >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.. >> 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? There is more than one way to do things.. Why copy some some ancient SysVism when it doesn't really do what everyone wants anyways? This should not be an argument, we are just exploring new possibilities here.. --Chris Csanady
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704272116.QAA11062>