Re: init script config files
Ethan Benson wrote:
>
> On Sat, Jul 08, 2000 at 10:38:30PM -0400, Christopher W. Curtis wrote:
>
> > If I wanted to persue 'my way', you could put all your custom code into
> > the defaults.d file, leave the init script alone, and have it preserved
> > without the init script being a conf file.
>
> nope, because in the case of bind i had to alter the way it was
> stopped and restarted, because the built in methods broke with the
> chroot setup. no way to do that without rewriting the initscript itself.
Sure you could. Change:
#!/bin/bash
. /etc/init.d/defaults foo
to
#!/bin/bash
. /etc/init.d/defaults foo $@
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.
> you want initscripts rewritten to use a bunch of functions held
> elsewhere. that is plain wrong.
>
> start-stop-daemon already uses exit status error reporting, what more
> do you need.
What I've done (re: creating functions) is not terribly different from
writing something like ssd - just another tool that can be used. My
code happens to be written in bash, not C. ssd does not document its
return values in the manpage; I haven't looked at the source.
> > I didn't set out to rewrite s-s-d, as said before. Consider it an
>
> that is what you ended up doing, reimplementing start-stop-daemon,
> poorly.
not. I provide a subset of ssd, plus a couple things it doesn't do.
> > out of the files that get overwritten on a package upgrade.
>
> you don't solve any problems, the config files will have to be
> upgraded too same deal.
Why if the script comes with sensible defaults?
> > Not the status I mean. Just that the same error always returns the same
> > error code. This makes doing the color status thing easy when doing a
>
> sucess == 0 failure == 1+ that is how it works now and its fine.
"1+" is insufficient for meaningful error reporting.
> you don't need some obfuscated script full of functions to implement
> exit codes, that should be done in individual initscripts.
No, you don't need it, but it can be made easier if so.
> > and all the needed checking (and consistent error reporting) is done
> > there.
>
> only if the rest of the script is rewritten to use all the functions
That's true - start, status, and [hup|term|usr1]. Since it doesn't try
to solve all the problems, the initscript will still have to do error
checking, there's just less that has to be put there.
> > [being prompted about replacing a changed conffile]
> > > > never said it was a bug.
> > > no you just said it should go away.
> > And I still say that.
>
> ok let me get this straight, asking permission to replace an altered
> config file is not a bug but it should go away? wtf.
I didn't say that it should not ask permission to overwrite a changed
file. I say that it should not ever need to do such a thing (ie:
configuration changes go in a different file).
Christopher
Reply to: