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