Date: Mon, 25 Sep 1995 13:20:30 -0700 From: patl@asimov.volant.org To: jmb@kryten.atinc.com, peter@taronga.com, gryphon@healer.com Cc: hackers@FreeBSD.ORG Subject: Re: ports startup scripts Message-ID: <9509252020.AA29198@asimov.volant.org>
next in thread | raw e-mail | index | archive | help
|> > > solves the rename problem. not the 'is it the same of is it not,
|> > > i have to did deeper' problem.
|> >
|> > Sure. If you do it right you just need to make sure it's a symlink.
|>
|> From: "Jonathan M. Bresler" <jmb@kryten.atinc.com>
|> > urg....symlink. two files. requires diff or ls -F to determine
|>
|> Agreed. I've said it before - symlink are only useful if you
|> (for some reason) can't put something where it belongs, of if
|> it really needs to be in two places at one: the latter translates
|> as "cannot be easily gotten at in the proper place" or "a non-optimal
|> location is hard-coded in something".
|>
|> There is no need to two sets of directorys off of /etc with
|> the contents of one being linked to the other.
You are right - it isn't NECESSARY. But it is convienient.
Because if you have a separate directory for -all- startup scripts,
you don't need to remember which run states or sequence numbers
they have when invoking them by hand. This is particularly useful
if you have any services which are not (yet) automatically invoked
at startup time.
It is also very helpful if you consider the different runlevels to
be independant states, not a monotically increasing set of levels.
And hard links are even more useful than symlinks. With hard links,
you can easily determine how many states are using a given script
simply by checking the number of links to the master copy.
|> > one directory for all run-states?? or one directory for each. i
|> > am advocating one directory for all start, kill and restart scripts.
|>
|> I still prefer run-levels (as opposed to states), but I'd still
|> rather see one directory per state than anything else.
Right. One directory per state, and one directory for the cannonical
location of the scripts.
|> > for instance: (concept, not correct implementation)
|>
|> > multi_user = "syslog cron"
|> > network = "syslog cron_net ifconfig named"
|>
|> Yep. That works. The only problem is shutting things down, if you
|> are not simple shutting everything down.
You need to document both what each state is ('single user', 'multi
user, no network', 'multi-user, network clients only', etc.); and
the sequence points within each level (from Solaris2.4 rc2.d/README):
After the S20 scripts have executed, local file systems are
mounted and temporary directories have been cleaned as
appropriate.
After the S80 scripts have executed, the machine is a fully
configured NFS client. NFS file systems have been mounted.
The name service (if any) is running. syslogd and cron are
running.
This documentation should be in README files in each rc?.d directory.
|> Actually, at that point you'd need a matrix of what to stop and start
|> depending upon what run-state you are going from and to.
|>
|> All the more reason to go with linear run-levels.
Not really - a stateX-to-stateY transition could be done by shutting
down stateX completely and then starting stateY from scratch. This
also avoids the crossbar problem.
My problem with run levels is that if I want a state which does not
correspond to any of the standard levels, it will probably need to
go inbetween two of the standard ones. (E.g. multi-user, with full
networking on the LAN, but no outside connection) If it is done
as levels, I'd have to re-number the levels to insert my new state.
If I then try to install a package that adds a startup script to
that state...
Also, I can easily conceive of desirable site-specific states where
neither is a subset of the other.
If the implementation supports states, it is easy to use it to provide
levels. (In each state, have S00. simply invoke ../rc[state-1]. [*])
If it only supports levels, using it to get distinct states is going
to be pretty tough.
[*] In practice, we'd want to be able to determine the current state
and only invoke the state startup scripts for level above the currently
active one. All this reversed for reducing level, of course.
|> > now i know that both use the same syslog start script
|> > and that they start cron differently.
|> > the order is explicit, not implicit ascii sort order
|>
|> Yep. Alternately, the "cron" script can take an argument of "multi-user"
|> or "network" and do the right thing.
Cron shouldn't need to know. And doing that limits the possible cron
actions choosable from the different states.
|> in summary, my druthers are:
|> > one directory for all start and stop scripts
|> > explicit invocation order, a list
|> > one name per script regardless of run-state/level
|> > (no links hard or soft)
|>
|> Yep. I'll buy that for a dollar.
I won't. My druthers are:
One master directory for start/stop/restart scripts.
One directory per run state, with hardlinks to above.
Invocation order dictated by digits in script name.
|> > explicit names: Snamed (start.named, whatever)
|>
|> Or two optional arguments to each script: the name of the run-state
|> or number of the run-level and "start"/"stop"/"restart". Even clearer.
Script names in init.d should simply name the service ('named').
Script names in rc?.d have 'S' or 'K' and a two (or three) digit
number prepended to dictate order and action. ('S*' are invoked
when entering the state, 'K*' when exiting it.)
|> > that both use a master file. one exists as a file, the other
|> > exists as an artifact of ascii sort order (not obvious to our poor
|> > newbie, especially when we have to explain that 10 comes before 2). a
|> > list of tasks/scripts is clearer to our newbie and easier for everyone else.
|>
|> A master file, which generates a set of run-state script. The program
|> which generates the "rc.N" scripts (N being run-state #) check for
|> consistency (ie major screw-ups, possibly even dependencies) before
|> replacing the older "rc.N" file. All the scripts reside in /etc/init.d
|> and take a single argument of "start", "stop", or "restart".
--- NO SCRIPT EDITING !!! ----
I cannot possibly overemphasize the advantages of a system which
avoids the need to ever automatically edit any file. This avoidance
is the single biggest advantage of the SVr4 model.
If all of our scripts have the same number of digits, there won't
be a '2' to come after '10'. It will be '02'. Just for emphasis,
we can mention that fine point of lexical ordering in the man page
and per-rc-dir README files. Anybody who is still caught by it
after that needs the object lesson they will get in tracking down
the problem. (And should probably consider a career which doesn't
involve any system administration.)
|> Very similar to what is now being done for "daily"/"weekly".
|> Which I've already done, so could do this one just as easily.
Personally, I think the daily/weekly cron jobs should also have
directories of sub-scripts, invoked in lexical order.
-Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9509252020.AA29198>