[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question about Facility names



   From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
   Date: 22 Nov 2000 06:04:08 -0800

   i do not like too much that, what does this bring more (except: back
   compat issue) ? Dependencies ? as acox say it could be in the files
   himself. I guess it could be doable in the current sysv scheme. The
   main rant of Richard for the current Sysv scheme is :

My big complaint with the Ssytem V scheme is that using numbers is
simply *stupid*.  What does it mean to start a script after S50?  I have
no idea, it depends on the distribution.  If only the distributions
provide init scripts, you can say sure, use chkconfig(8) (although
that's not standard across all distributions, and doesn't work all that
well in my experience).  But if a sysadmin wants to add his/her own init
script, it's not at all obvious where to add it, without having to trace
through all of the various init levels.  Trying to figure out what the
heck is going on is not at *all* obvious.

Sure, if you create a dependency loop, the init system can't start a
number of services.  But if you assume that core system scripts are sane
(because they are provided by the distribution) it's actually very
unlikely that the user will add something that will completely screw up
the system and prevent it from booting --- in order to do that he/she
will have to be modifying the core system scripts, and they're just as
likely to break it one way as another.

And for "non-core" scripts, where the user has added two or more scripts
which causes a dependency loop, they're just as likely to have lost
because they used the wrong S* number and started it before some
required service was required.    That's why I think the dependency loop
argument is a bit of a red herring.

As far as the complaint of needing to read the whole script in order to
find the depencies, that's a fair argument.  There are ways around that
though, simply by using coding convention.  Instead of doing this:

# need: foo bar
# provides: baz quux

you just simply have to do this instead:

NEED="foo bar"
PROVIDES="baz quux"

at the beginning of the shell script, and then reference the shell
variables later on in the init script.  That's a pretty easy way to
solve the problem.

							- Ted



Reply to: