Re: init script config files
On Sat, 8 Jul 2000, Christopher W. Curtis wrote:
> As I said initially, and said specifically to you, it is not, cannot, is
> should not try to be a end-all solution. Every initscript that uses
> defaults.d (config.d - whatever) does *not* need to be a conffile. And
> should not be. Why? Because anything that can be configurable belongs
> in the configuration file, not in the script. If a script can't put
> everything in there, then it must be, yes. This is a way to get a chunk
> of them out of that hairy (mho again) situation.
But sometimes not everything can go in it. When your script only switches
lights on or off, some variables may reach. But image other
situations. The User want to add some parameter to a call or call another
programm. You can make everything a Variable, but what about adding a
command? So you could make the User (=admin as non maintainer)
change the subrotines in the xy.user file. But then it get very hidden,
what it does, when somebody else want to change something. He looks at the
script itself, thinks he know what is done, but it is overridden.
This is no nice solution to the situation.
> How does SuSe handle this? Caldera? TurboLinux? We know that RedHat
> and HP-UX do it something like this - maybe there's a very good reason
> for it. Are you arguing that it's easier to keep things consistent when
> you have 100 different people writing every init script from scratch?
> Or do you just not care about consistency and/or maintenance?
I had to change a little bit on a system boild on top of an old suse.
It was terrible. The script called a script, which called onother, which
called the first with different paramters which called aanother. After the
15th (!!) script I got lost. (Perhaps earlier,but I didn't notice before).
So I compared the file it got it input from with the man-page of the
command to be invoked and guessed what it should do. (It took me 4 hours,
before I did so, because I had to search the file manually, it wasn't
mentioned anywhere in the first 15 scriptfiles).
What I kept was a nightmare against any script-system, one calling each
other. One file mit Variables may be OK for easy changes, so that dpkg
can overide the main-sript, because it is not changed. But the file itself
should almost always be a conffile.
And people don't have to write everything from scratch. They have s-s-d.
It is the debian way of making it clear and simple.
>
> Your argument (which you deleted) was that modifying a script was easy
> doing it 'the old way'. This simply shows that doing the same was just
> as easy 'this way'. It is not to be used as an example of anything
> else.
>
I think your problems for signals and error messages are not a reason for
not using start-stop-daemon. If it doesn't show something you want to
have, it's time for a wishlist-bug against s-s-d for a new option.
> How is it fored on you? If you write scripts, you're not forced to use
> it (though users might make that suggestion); if you just run it, you
> can still edit the file manually.
If ii is no conffile he cannot edit it, because it is dpkgs task. If he
still does so, dpkg will get mad and override it with the next upgrade.
> I think you might be in the minority, then, as anyone who has used kill
> should be able determine what "stop) term foo;;" and "restart) usr1
> foo;;" *probably* do.
You can imagin what they propably do. But when you have strange behaviour
and the subrotine is not 2 lines above, it still gets terrible.
> nope. I see what it does, it does a lot, and it doesn't really seem as
> useful as something tailored to initscripts. As I'm pretty sure I've
> said, this is fine for executing programs, and can be useful in my own
> script, but does not replace the ability to do things like "start) start
> foo; status $?; exit $? ;;". [NB: In my own code, I added "return $1"
> to the end of the status function to make this work. Also eliminates
> the need to save $? in the generic case.]
I don't know, if s-s-d already is able to. But when not fill a
wishlist-bug against s-s-d.
> Nothing is hidden from the admin. Comments are generous.
By a subrotine term, which encapsulate the real call, it get's hidden by
showing the code in an more abstract way. I think s-s-d's attemp is to
make it such easy and abstract, so hiding it has no benefit.
> It certainly won't. The initscript can be removed and the user created
> config file can remain.
And when the user has to edit the initscript?
> I feel like I'm writing to a wall. Don't want to use the functions?
> Don't. Want to include the file directly? Fine. To the end user, it
> all works the same way.
If it is no conffile, the user cannot change it.
> Either way - if the script uses defaults.d and everything you need to do
> can be done from there, there's no need to modify the initscript.
But not anything can be a variable in an clear and easy way. And when all
is possible you get a very teribble system.
Hochachtungsvoll,
Bernhard R. Link
Reply to: