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

Re: init script config files



Ethan Benson wrote:
> 
> On Sun, Jul 09, 2000 at 12:07:26AM -0400, Christopher W. Curtis wrote:

> > Rewrite the script in /etc/config.d/foo - you get persistence and
> > conffile isn't needed on the script.  Please note that I'm suggesting
> > this be done, simply that it is possible.
> 
> why would i do that when i could just rewrite the initscript to do
> what i want?

Either way you're rewriting the script.  One lives in init.d, the other
config.d.  The assurance is that config.d will never change unless you
manually change it.

> and besides that you still have to edit the script anyway to get rid
> of the starting and stoping since those are items i have had to redo.
> (again bind)

No.  Put 'exit 0' at the end of config.d/foo and it exits 0.

> so why not document start-stop-daemon, or perhaps add more return
> codes.
> 
> > not.  I provide a subset of ssd, plus a couple things it doesn't do.
> 
> and your script lacks much function that start-stop does have.  and

Because it is not meant to replace ssd, and the additional things that
it does do are not proper to be part of ssd as they have nothing to do
with starting or stopping daemons.  (eg, status)

> > Why if the script comes with sensible defaults?
> 
> um because things change, variables may become obsolete or need to be
> changed in some way.

Your implication was that the defaults would change each time the init
script is updated, which I assert is simply not true.

> > "1+" is insufficient for meaningful error reporting.
> 
> rubbish.  there are plenty of return codes to use.

If they are defined.  You defined 0 success, anything else failure.

> > That's true - start, status, and [hup|term|usr1].  Since it doesn't try
> 
> hence become obfuscated. just like redhat's

Using those functions does not meet the definition of obfuscate.

Christopher



Reply to: