On Mon, Apr 28, 2003 at 03:43:25PM +0200, Joachim Breitner wrote:
>
> A runlevel is just any script whose name makes it being called by
> /sbin/init on a certain runlevel, like
> /etc/init.d/runlevel.3
> There is nothing special about this script, it could do anything you
> want. Usually I think it will only print out messages like "Dude, this
> is runlevel 3" and <need> all the packages that should be started in
> runlevel 3. It may have the line "need runlevel.2" at the beginning, but
> thats totally optional. You could also make runlevel 3 build upon
> runlevel 4, or none at all, or even make it dependant on something (eg
> runlevel 5 starts either runlevel 2 or runlevel 3, depending on whether
> it is started on weekends or on regular days).
The problem with simpleinit is that it only really worries about how
to start up stuff, and the only mechanism it has for shutting down
scripts is by using the rollback scheme, which assumes that things
should be shutdown in the reverse order that they were started.
An inherent assumption of this scheme is that you need to know when to
do a rollback and when to execute a need. For example, suppose you
want to go to run level 3. Should you execute /etc/init.d/runlevel.3?
Well, if you're at run level 2, then presumably, yes. But suppose
you're at run level 4? In the Richard Gooch view of the universe, run
level 4 always has more stuff started than run level 3, so the right
answer is that you tell init to rollback to run level 3. (It also
assumes that you went through run level 3 on the way to run level 4
--- otherwise, simple init will start shutting down processes until it
finds run level 3 or it runs out of startup scripts. So if you didn't
stop at run level 3 before going on to run level 4, the rollback
command will happily kill off all of the daemons in your ssytem before
running out of startup scripts. Oops.)
Basically, the fairest thing to say about simpleinit is that it
doesn't have the same functionality as run levels, and it gives up
some of the generality of run levels in the name of simplicity. But
as a result, its emulation of run levels is at best imperfect, and
there are definitely things that you can do with run levels that you
can't do with simpleinit.
Specifically, with run levels you can specify a different set of
scripts to start *and* stop, whenever you enter a particular run
level, and you can enter run levels in any arbitrary order. So you
can go from run level 2, to run level 3, to run level 5, to run level
2. and then back to run level 3. (For example.) You can't do this in
simpleinit, because the only way to stop daemons is via the rollback
mechanism.
Does this matter? It depends on what system administrators have
utilized run levels for. Historically Debian has given a lot of
leeway to system administrators to use run levels however they wish.
So it is certianly not the case that simpleinit could never be a
replacement for sysvinit. That might be considered by some to be a
feature, but I for one was left wishing that Richard had spent a bit
more time worrying about backwards compability, so that simpleinit's
abilitys could be a superset of sysvinit, and not a subset.
> Dependecy informations in script comments are a bad idea:
> * You are limited in type of script (shell, perl, C, vbs) you want to
> use.
I'm not sure it would *ever* be a good idea to use a C executable in
an /etc/init.d startup. And in fact, historically most people have
considered it wise to simply use /bin/sh for init scripts for maximal
portability.
> * You can't use dependency conditinal, like in:
> if any remote file systems are to be used via an interface that is a
> ppp device, than depend on pppd unless the file system is marked noauto
> or the target host is already pingable for some strange reason
> Ok, the example is bad, but having laptops and other mobile devices
> in mind, that have to be very flexible in a lot of ways, this is an
> advantage.
Be very careful here. A real danger with dependencies is that you get
yourself into a circular dependency which just wedges the entire
system up at boot time. Merely *adding* a pacakge can get you into
trouble where the system will no longer boot, but simply looking up a
deadlock of unsatisfiable need commands. Actually, what simpleinit
will do is simply ignore the need command the second time it is
called. Which means that if there is a circular dependency, a
(randomly chosen, depending what script wins the race) dependency is
simply ignored.
Ignoring a dependency is probably bettter than a deadlock which makes
the system unusable, to be sure, but it means that it is essentially
impossible (equivalent to the halting problem) to do any kind of
static *or* dynamic analysis to determine whether or not adding a
particular script to the system is safe or not.
- Ted
