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: