On Fri, Feb 18, 2000 at 02:20:20PM -0500, Theodore Y. Ts'o wrote:
> From: Anthony Towns <aj@azure.humbug.org.au>
>
> What's the point of `Default-start' and `Default-stop'? For one,
> run-levels on different distributions mean different things. For another,
> run-levels on different systems mean different things. I wonder if this
> wouldn't be better being just a system-wide default (all new packages
> go into run levels 2, 3, 4, 5), and/or depedant on the `Required-Start'
> tag (if it depends on X, only start it in runlevel 5)
> The LSB defines the meanings of the runlevels. So the idea is that we
> will be standardizing this. For the most part the meanings between the
> distributions are really close at this point.
This seems a bit of a loss to me. We (distributors trying to comply
with the LSB) already have to do a little clever programming to deal
with the dependency stuff, why not do a little more of it and give
people the freedom to define what runlevels mean what?
I raised this [0] in response to Dan's proposal to some degree of
consensus, I thought. :-/
I'm not against standard runlevels (from a "help the admin" perspective),
but I don't think third-parties should be relying on neither the
distributor nor the admin changing things around.
install_initd fooserv --runlevel=multiuser,network
install_initd superlogger --runlevel=singleuser
seems like it wouldn't be particularly difficult to implement, and a lot
more flexible. Especially since install_initd will already have to be
smart enough to translate `Requires: $network' to `S24/K68' in most cases.
> What's `Required-Stop' header for? Other services that should be stopped
> before this service? That might be cumbersome. For example, the portmapper
> ought to be stopped after the NFS server, but you probably don't want to
> have:
> It probably should be "Required-to-Stop". The idea was to say that this
> script should be run *before* you shutdown the network (for example).
> It might or might not be the same as the Required-start list. I wanted
> to keep it separate to make life easier.
Ah. So NFS would be:
# Required-Start: portmap
# Required-Stop: portmap
That makes sense. (Being the feeping-creaturism fan that I am, I wonder if
`Required-Stop:' should default to being the same as `Required-Start:' if
its not present)
> > it must not be run until certain boot facilities are provided. This
> > information is used by the installation tool or the boot-time
> > boot-script execution facility to assure that init scripts are run in
> > the correct order. =20
> This seems like it could be a nuisance to achieve with existing SysVinits;
> there's only so much room for dependencies between S30foo and S40bar.
> It doesn't matter. You can have multiple shell scripts that all begin
> with "S31". The rc scripts simply using the numbering scheme so that
> the scripts get alphabetaically sorted. If you have 20 scripts that
> depend only on the fact that S30foo has run, you by definition don't
> care what order they run in, so they can all get linked in as S31bar,
> S31quux, etc.
On the other hand, suppose you have half a dozen scripts that all need to
be run in a specific order. (foo, bar, baz, quux, blah, and blat, say)
Suppose you have the range S30-S40 to play with.
You install foo, it gets put at S30.
You install bar, which depends on foo, it gets put at S35.
You install baz, which depends on bar, it gets put at S37.
You install quux, which depends on baz, it gets put at S39.
You install blah, which depends on quux, it gets put at S40.
You install blat, which depends on blah, and....?
I suspect you could probably just rearrange the scripts at this point,
without too much stress, but it's still complicated, if you have too
many inter-dependencies. In general, and so on.
> Also, what should happen if a dependency *can't* be met? For run-scripts
> I just treated the `provides/needs' clauses as advisories, and ignored
> any circularities or missing scripts. Anything more complicated at boot
> time seemed unreasonable.
> The dependencies are designed to be as high-level as possible, in order
> to prevent this kind of thing. Using "Provides" is especially
> discouraged, and a LSB-application won't be allowed to "Provide" a
> system service. (In fact, initially as a simplifying assumption we may
> not want LSB applications to provide any services at all.)
Hmmm. That's probably not a bad idea. It also means we only need a couple
of Sxx levels for LSB applications, one for each $foo dependency they
can declare. (ie, if you depend on $usr_mounted, we'll put you at S11,
if you also depend on $network, we'll put you at S21, and so on)
Yes, that makes everything simple and neat and wonderful.
> > log_success_msg "message"
> > log_failure_msg "message"
> > log_warning_msg "message"
> What do these buy us over `echo' or `gettext -s' ?
> It allows a distribution that wants to do something fancy, such as being
> able to display success messages in green, warning messages, in yellow,
> etc., a way of doing this.
I was thinking that just having `echo foo' for log_success, and `echo >&2
bar' for log_failure would be good enough, but it isn't very pretty is it?
I wonder if something like:
log_attempt "Starting foo daemons:"
for d in bar baz quux; do
log_attempt " $d"
start_daemon $d
done
log_success "."
would be reasonable (with log_attempt='echo -n', eg). Being able to tell
exactly which daemon is hanging for ten minutes or crashing your system
is really nice. I can't think of a tidy API for it though.
Cheers,
aj
[0] http://www.debian.org/Lists-Archives/lsb-spec-9904/msg00026.html
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpVnEftVEoLd.pgp
Description: PGP signature