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

Re: init script config files



[mass cc cleaning; does this belong in -policy?]

Ethan Benson wrote:
> 
> On Fri, Jul 07, 2000 at 10:44:15PM -0400, Christopher W. Curtis wrote:
> >
> > My idea is to have a script, '/etc/init.d/defaults', which every init
> > script sources.  'defaults' will read the default settings and define
> > common functions for the scripts to use.  Here is a rough draft of the
> 
> this is exactly how redhat does it and it **S U C K S**
> there should be shell variables thats *IT*
> 
> no fscking functions
> no fscking sourcing (except for the init script sourcing its *ONE*
> config file (which contains ONLY simple shell variables)

Why do you feel this way?  A lot of the debain scripts contain stuff
which seems non-obvious to me, and they (pretty much) all do the same
few basic things: start programs, stop programs, and display messages. 
Why is it wrong to combine these?

Furthermore, making it a policy to source one config file (it should be
two - one default, one user override) to read a bunch of environment
variables would make a lot of the scripts even more confusing/convoluted
then they already are.  That just doesn't seem like a good thing(tm) to
me.

> no all scripts should only include the script config file
> /etc/default/portmap (or whatever)

Also realize that some packages contain more than one daemon.

> > doing so.  The script will make sure the the environment for running the
> > package is sane, and provide functionality to start any programs it
> > needs (start) and to send them various signals (hup, usr1, etc).  It
> 
> noooooooo!  this is the horrible crap redhat does.  its buggy, broken,
> obfuscated, crap.  /me considers moving to slackware or *BSD.... sheesh.

Look at the tarball I sent as a followup - it's really not that
complicated, and it can still be up to the script writer to chose to use
it or not.  I have a total of five functions: start(), status(),
generic_kill(), then hup() and usr1().  The only other thing that I can
see wanting to be added is more signals - eg, kill(), and usr2() - and
these constitute a mere 5 lines of code each, including comments.

> [snip obfuscated ball of redhat spaghetti]

Come now - I've had to deal with RedHat init scripts and this is nothing
like them (nothing like the ones I had to debug in 4.2 or 5.2, anyway). 
One sourced file from the init script.  That file sources a default and
user option file sitting in defaults.d/packagename.  The goal is that
these files are the real variables, and nothing more.  Sourcing the
'defaults' file simply handles it for you, adds a couple extra checks
that would have to go into the script anyway, then provides a few
functions which I think should be encouraged but which need not be used.

> apologies for the flame but one of the *primary* reasons i switched to
> debian is to escape redhats fucked up initscripts which you just
> described in your proposal.

RedHat goes far beyond what I've done ... 

Christopher

[The code actually allows commandline arguments to be passed into the
file containing only variables; so yes, it could get confusing, but it
was trivial to add and might just be useful for some scripts so I left
it in.  Better to err on the side of flexibility in this case,
methinks.]



Reply to: