Date: Sun, 27 Apr 1997 15:33:53 -0700 (PDT) From: patl@Phoenix.volant.org 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: <ML-3.3.862180433.7419.patl@asimov> In-Reply-To: <199704272116.QAA11062@nyx.pr.mcs.net>
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 > >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. If it's a function, what do you need to do to make that function avaliable to your shell? And which shells would be supported? The script-with-start/stop/restart-parameter solution is a clear win for manual use because it imposes no restrictions on the user's choice of shell. Or, for that matter, on the shell to be used in the start-up script itself. In fact, there's nothing that says that the start-up program needs to be a script - it can be any executable file. This is a Good Thing. > 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. ;-) Oops, that means there's more to 2) than just adding a script. And unfortunately, it means editing a file. Which is something that I really don't want automated installation/removal scripts to have to do. In that regard the directory is -MUCH- easier, simpler, and safer. > 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.. How about sticking with the sequence prefix so that a simple 'ls' tells you what you need to know? No new tools or options to remember. (Remember, a lot of us don't need to do this very often. It's easy to forget options that are rarely used. On the other hand, few will go more than a day without doing an ls somewhere...) > I think it is obvious that at least a few things need to be worked out. > That shouldn't stop us though, right? :-) Right. And if you can come up with something that is better than the Solaris2-style approach, I'll be the first to champion it. But some of the metrics for 'better' include reducing the number of new things you need to learn and remember to use it, retaining flexability, and simplicity. The Solaris2/SvR4 approach is simple. (The per run-level implementation is simple - the multiplicity of run levels is a bit of a hurdle for those of us who are more used to thinking in terms of 'off', 'single user', and 'multi-user'.) > >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.. Right. But how can you handle it in a clean, flexable, simple manner? If you only needed to worry about those services that are bundled with the system, it would be manageable. But different sites will be adding third-party packages and replacing standard components with external implementations. Look at all of the sites that replace sendmail with another mail transfer agent. How do you abstract the dependency from 'sendmail is running' to 'a mail transfer agent is running'. Ok, now how do you do that abstraction for EVERY service or combination of services? I don't think it can be done. In my opinion, a better approach would be to make the start-up script for the dependant service actually test for availability of the dependancies. Using the sendmail example, don't trust the MTA start-up script's result code, actually attempt to connect to the SMTP port. > >> 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? Like I said. As long as it is kept simple, obvious, and flexable, I'll jump at it. > 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.. So let's identify what it doesn't do, and what it does, so that we can start from a requirements list instead of an implementation proposal. (I think one of the biggest mistakes in the SysV implementation was in calling them 'run levels' instead of 'run states'. Their implementation certainly isn't a nice linear progression of levels...) Let's also remember that we don't have to be different just for the sake of not looking SysV-ish. Gratituous differences help no one. In fact, when choosing between implementations which are otherwise equally matched, the familiar, compatible approach should be favored. (Note that in this case 'familiar' encompasses not just previous FreeBSD users; but users of other unixes as well. With some weighting being proportional to percentage of installed base.) And remember - no matter how many ways you imagine it being used, someone, somewhere, will have a legitimate reason for wanting to do something you never thought of. Let's try not to get in their way... -Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ML-3.3.862180433.7419.patl>