Re: Re: Two line init.d scripts? Sure, that will work!
>> Peter, thank you for your work. Have you tried any complex init
>> script to fit this business (apache2 or postfix, for example)?
>
> Nope. It is ment as an option for the packages with simple needs.
> Those with complex needs can use it too, probably, but it might be
> easier to just keep the current init.d scripts.
They aren't too complex, actually.
> Ah, good point. Added do_start_cleanup and do_stop_prepare hooks to
> cater for such needs.
Probably, we should have hooks,
that can be invoked before specified action (e.g. start or stop)
and after. But not just for start/stop.
BTW, there is try-restart action, mentioned in the LSB. Probably,
you should add this. And you can implement some standard
do_reload function (with HUP signal), disabled by
default; the package maintainer can enable this with one-liner like
alias do_reload_override=standard_boilerplate_for_do_reload
Also, a very common pattern is to specify some daemon
options somewhere in /etc/default/. Probably, it's a good
idea to include /etc/default/$YOUNAMEIT file and use
some variable (e.g. $OPTIONS) to provide additional
arguments to do_start_cmd/do_restart_cmd/do_reload_cmd.
>> Also, there is the do_rotate function - a very common example when
>> you want to implement a custom action (not just one from fixed set
>> start/stop/reload/etc).
>
> Not quite sure if that is within scope of this mechanism. Will think
> more about it.
You can add a specific helper to be invoked if a non-standard
action is specified. Only if that helper doesn't exist
OR fail with status code 3 - call usage(). Then exit with the
provided status code (or 3).
> Multiple daemons is definitely out of scope.
I don't think that it's a bad idea to think about.
PS:
> PS: Peter Reinholdtsen is my distant cousin.
Sorry for typo :(
Reply to: