Re: init script config files
Ethan Benson wrote:
>
> On Sat, Jul 08, 2000 at 01:16:42AM -0400, Christopher W. Curtis wrote:
> >
> > 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
>
> the majority of debian initscripts are elegant in their plain
> simplicity. its very obvious exactly what is occuring and its very
> clear how to make changes (say add a command line argument)
Well ... I think we're just going to disagree here, because I think this
way makes init scripts simpler, more elegant, more clear. and less
fragile.
The reason for this thread was because changing something in an init
script does not persist, and the whole mess (it's a mess imo) about
'removing' something versus 'purging' it can basically go away.
All user changes go into /etc/init.d/defaults.d/PACKAGE.user (this is my
notation and can surely be changed) and this is the only file the user
should have to change, ever. When the package is removed, the scripts
can go away as well so there's not a bunch of scripts running at boot
time checking for -x (or -f) of their daemons in the case that it was
removed but not purged. (Yes, my code makes the same checks, but it
does so for error conditions, not 'what kind of messed up state does
debain require I be in'.)
Adding a commandline argument, using the example I sent, means changing
the variable "OPTIONS" in /etc/init.d/defaults.d/foo.user. If this is
non-obvious, a comment can easily be added so that:
. /etc/init.d/defaults foo
becomes:
# Defaults (settings) are in /etc/init.d/defaults.d/foo
# User overrides go into /etc/init.d/defaults.d/foo.user
. /etc/init.d/defaults foo
Modifying the script (ie, by the maintiner) to add a variable would go
something like:
edit /etc/init.d/foo:
start)
start foo
to be:
start)
start foo $PORT
and adding to /etc/init.d/defaults.d/foo
PORT="1025"
> > few basic things: start programs, stop programs, and display messages.
> > Why is it wrong to combine these?
>
> because not all daemons are alike, each has thier own subtle needs,
> trying to make a one-size-fits-all shell script `library' will only
> cause bugs, and make the script less clear and harder to modify.
Like I said in my very first message - it won't handle all cases, I hope
it will handle about 80% of them though. Nobody is forcing anyone to do
anything.
Adding these functions allows a consistent errorcode mechanism to be
implemented trivially for those daemons that can use it, which is
something I think that debain should have and this provides.
> tell me why it is somehow more desirable to have:
> generic_kill() `pidof sshd`
> instead of say:
> kill -15 `pidof sshd` or
> killall sshd
I don't say that it is. I say that
term sshd
is clearer and more consistent than
kill -TERM `pidof sshd` or
kill -15 `pidof sshd` or
killall sshd or
kill `cat /var/state/sshd.pid`
because (unlike kill -15 especially) it plainly states what it is going
to do, and it does basic error checking to make sure that the program is
running, that the kill is successful, is quiet about it (no "kill: no
such pid" cruft being spewed to stderr), and returns a consistent error
code so that other programs (such as the included 'status' function) can
print pretty and useful messages to the user, like "^[[1;4aProgram not
running^[[0a" (sorry, I forgot my ANSI codes).
> or start-stop-daemon --stop --quiet --exec /usr/sbin/sshd
Yes, there is duplication with start-stop-daemon. I am not intimate
with SSD and I read the manpage - it seemed complicated and I just
wanted something simple. However, if people like this, I would be quite
content to have 'start', et al, use it. It can do things that I am
unable to do in bash, and it already exists. However, I would still
wrap it in 'start()' &co so that error checking can be moved out of the
init script and into this 'library', and so that consistent error
messages can be implemented - trivially and consistently.
> > 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
>
> why?
So that new init scripts can be installed without destroying user
settings or intervention by the SA, and old ones can be safely removed
at 'remove' time, not 'purge' time.
A (I hope) pertinent example: I don't like portmap in the required
package netbase. I don't like the existing "solution" for diasbling
it. Why? This is me. Who cares, I'm providing an alternative. Look
at /etc/init.d/portmap. I'm going to rewrite this script using my
'defaults' library as example:
--------------------------------------------------
#!/bin/sh
#
# start/stop portmap daemon.
. /etc/init.d/defaults portmap
if [ "X$RUN_PORTMAP" != "X1" ] ; then
exit 0
fi
case "$1" in
start)
start /sbin/portmap
error=$?
status $error
# [ There is cruft here that looks like it
# can be removed from both files]
;;
stop)
# note: start-stop-daemon uses "--stop" to stop a daemon, but it
# does not send it SIGSTOP. Very confusing. I'll use TERM.
term portmap
error=$?
status $error
;;
reload)
force-reload)
restart)
pmap_dump > /var/run/portmap.state
$0 stop
$0 start
error=$?
if [ -f /var/run/portmap.state ] ; then
sleep 1
pmap_set < /var/run/portmap.state
rm -f /var/run/portmap.state
fi
;;
*) echo Usage ; exit 1;;
esac
exit $error
--------------------------------------------------
Now, as you can see, I've removed stuff that shouldn't be in there,
abbreviated the *), reload, and force-reload entries, and moved the 'rm'
line around, so size doesn't matter. What is important to see is that:
*) There is a new check to see if portmap should be run, since portmap
is not it's own package. (explination below)
*) There are no "echo" statements for start/stop.
*) Errors are handled much more gracefully (except the portmap.state
stuff, which I left alone).
Now, this needs a single auxilliary file,
/etc/init.d/defaults.d/portmap, which would look something like this:
--------------------------------------------------
# 'portmap' is installed as part of netbase. You cannot remove netbase,
# as it is a required package, so here's your chance to turn it off.
# Set RUN_PORTMAP=0 in /etc/init.d/defaults.d/portmap.user
RUN_PORTMAP=1
# Setting this make the script chatty
NAME="portmap daemon"
# And the messages for stopping, etc:
TERM="Stopping $NAME"
--------------------------------------------------
Now, if the user wants to turn off portmap, (s)he can just:
echo "RUN_PORTMAP=0" > /etc/init.d/defaults.d/portmap.user
and this will persist even after the package is updated, if it is
removed and all the init scripts go away, and an upgrade will not result
in in a conflict for the SA to have to manually deal with.
> > 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.
>
> then perhaps we should forget the entire enterprise. your method
> makes things FAR more convoluted and complicated then a couple simple
> variables will.
We disagree here as well. Adding any variables is going to add
complication. Having a default library simply takes some of that
complication out of the init script and puts it out of direct sigh,
which is, to me, less convoluted, and makes writing init scrtipt less
complicated.
The only difference is that I'd encourage script writers to deal with
error conditions, which currently are by the large ignored.
> i am still not entirly convinced the config.d idea is a good one
If it makes the "/etc/init.d/foo is different, replace? (yntfdok)"
messages go away, plus lets me get rid of running portmap from netbase
without doing a hack (yes, I feel it's a hack) to tell the portmap to
stop in all runlevels via a relatively obscure update-rc.d mechanism, I
much prefer it. Especially since init scripts are generally simple
anyway - I don't think something like this would work for, say, the
samba and squid configuration files. (Although, as an aside, if samba
and squid had a directive to read another file to override the settings
in the default file, or a setup like pine, it would certainly be useful
to have an /etc/config.d/package setup).
> > Look at the tarball I sent as a followup - it's really not that
> i still hate it, sorry.
<shrug>
Maybe I'm willing to make writing things more complicated if it makes
administration easier, and you're not. We just have different
perspectives that way. But overall, it seems easier to me.
But since I'm not involved, I can only contribute code ...
Christopher
Reply to: