Re: Initscripts management proposal
Date: Sat, 19 Feb 2000 01:46:31 +1000
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.
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.
> Additional keywords may be defined in future LSB specifications.
> Distributions may define local extensions by using the prefix
> "X-<distribution name>" --- for example, "X-RedHat-foobardecl", or
> "X-Debian-xyzzydecl". =20
What's with the "decl"s?
"Declaration". "Default-Start", "Required-Start", are all
declarations. Sorry if my notation was confusing.
> 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.
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.)
> In a multiline description, each continuation line must begin with a
> '#' followed by a tab character. The multiline description is
> terminated by the first line that does not match the '#','Tab'
> continuation specification.
I'm inclined to think an optional `/etc/init.d/foo about' would make
more sense here. Easier to get at, and (as I understand it) easy to i18n.
You may be right. I personally don't see the point of
internationalizing system startup scripts, but someone is going to want
to do it, and someone will be very happy to sell the gigagntic disk
space required to support it all......
I'd be a lot more comfortable, too, if there was a proof of concept
implementation of this that worked with the existing SysVinit startups
Debian (and RH? and everyone else?) use and the `requires/provides'
stuff discussed above. ie, one that somehow translates the dependencies
into Sxx and Kyy numbers.
If we take out the "Provides" line, and simply only have the Require
lines with certain specific system-defined facilities, it will be
trivial to map the facilities to a distribution's Sxx and Kxx numbers.
> Facility names that begin with a dollar sign ('$') are system facility
> names, defined by the LSB, and MUST be provided by distributions. LSB
> applications should not provide system facilities. This document
> defines the following system facility names:
>=20
> $local_fs all remote filesystems are mounted
> $remote_fs all remote filesystems are mounted (note
> in some cases /usr may be remote.
Is there any reason these are separate? `$usr_mounted' or something
would make more sense to me. What, if any, certainty does depending
on `$local_fs' alone buy you?
Good point. $usr_mounted is probably the right answer.
So that's just a note. For machines with changing network situations,
network services can be weird. They can need to be told stuff about
their particular environment, and can need to be restarted. They're
kinda special.
Very true. Supporting this right seems like it should be left to a
future version, although thinking about ways to make sure we don't
preclude something like this would be worthwhile. Being able to run
some rc.scripts triggered on external events like bringing the network
up, independent of the runlevel, is definitely something to think about.
> $named named is operational
Hmmm. I wonder if this shouldn't be almost implicit in $network. Before
the $network is up, you should have everything you need in
/etc/hosts. Immediately afterwards, you should have bind running.
One of the reasons I had separated things out was to increase the
possibility for more fine-grained parallelism to exploit. Some
subsystems (such as the Comtrol VS-1000, which operates at the raw
ethernet level) don't require named, and could be started up as soon as
networking is set up.
That said, what about $portmap, needed for NFS, and presumably other
things.
> $netdaemons all network daemons are running
What's this for?
Right, and that's what $netdaemons was for (portmap, and other daemons).
> Script names
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 1) Assigned namespace. This namespace consists of names which
> only use the character set [a-z0-9]. This space is
> desireable for scripts which system administrators may
> often wish to run manually: e.g., "/etc/init.d/named
> restart"
This is /etc/init.d/bind restart in Debian. /etc/init.d/ names in Debian
are taken after the program providing the service, not the service itself;
so if you want to restart the SMTP daemon, you need to know which one
you're actually running (/etc/init.d/sendmail, exim, smail, postfix, etc).
Yes, and I deliberately didn't want to get into trying to convince
some number of distributions to change their conventions, since it's not
needed; we just need to make sure that both bind and named are reserved
so that an LSB application doesn't try to grab bind or named. Those
names have to be reserved for distributions.
> In order to avoid conflicts these names must be reserved
> through the LANA (Linux Assigned Names/Numbers
> Authority).
LANA doesn't actually exist at this time, right?
Correct, although hpa has been doing functions similar to that for the
devices.txt file. And Eric Youngdale did something similar for the
a.out shared librarsies. It's simply a central namespace manager.
There's a list of the 250 or so init.d scripts currently in Debian at
http://master.debian.org/~ajt/initd-scripts.txt if that's of any help.
Thanks, that will be useful to look at.
> While the distribution-provided aliases may
> choose to use bash extensions (at the distribution's option), the LSB
> init.d files themselves should only depend in /bin/sh features as
> defined by POSIX.2.
Or specify /bin/bash as their interpretor? (And have the entire package
Depend: on bash, presumably)
There's probably no big deal eitherway here. Note that their are lots
of little bashisms people fall into when /bin/sh is bash. Using `=3D=3D' in
[ ... ] clauses, instead of `=3D' for example. It may be a better idea
just to encourage people to use /bin/bash and be done with it, as far
as the user experience goes.
We could do this, but then we then have to define all of the bash
extensions in the LSB. It's rather bad form to say "whatever extensions
existed in bash as of 2.x.y". :-)
> 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. Of course, a distribution that doesn't want
to play such games can simply make all of these be "echo".
- Ted
Reply to: