[Pkg-sysvinit-devel] Make init.d/skeleton a very simple init.d script?

[Henrique de Moraes Holschuh]

On Mon, 03 Feb 2014, Petter Reinholdtsen wrote:
> [Henrique de Moraes Holschuh]
> > I think it would be best to have a way to override the actual
> > commands used to start/stop/restart/force-reload.
> 
> Yeah, I suspect so too, and spliting the functions in two is probably
> the way to go then.  Perhaps use do_start() and do_start_cmd() and
> similar?

That would do it, yes.

> > Also, we need to document how people should override things,
> > redefining the functions is not obvious _and_ a shell might decide
> > to spew out warnings, so I favor the "{$foo_override:=foo}" way of
> > calling these functions...  if it looks like "dh", it is more likely
> > people will use it correcty :-)
> 
> Can you rewrite the code to be the way you propose, to give me a
> better idea how you vision it?  Btw, when can shell spew warnings when

I have mostly email-only access while at work, ssh is not working well here.

One possible way to do it would be:

do_stop()
{
	if "command -v do_stop_override"; then do_stop_override "$@" ; else
	  our reference implementation of do_stop
	fi
}

This is both easy, and obvious.

An alternative still obvious to the eventual reader (and more powerful,
since one won't be as constrained on the override) would be:

do_stop_cmd()
{
	killall...
}

do_stop_default()
{
	#reference implementation of do_stop, override using the
	#do_stop_override variable or do_stop_cmd_override if you
	#just want to change the killall to something else.

	...
		${do_stop_cmd_override:=do_stop_cmd}
	...
}

do_stop()
{
	# call the shell function named in the do_stop_override variable,
	# if any.  Otherwise, call do_stop_default.
	${do_stop_override:=do_stop} "$@"
}

> redefining functions?  Never seen that myself.  I fear we "polute" the
> environment name space too much by adding variables for every function
> we can call, but perhaps we should not care about that much.

It is not much of a pollution problem, since none of these variables are
exported.  I don't think we have to fear a dozen local variables.  That
said, we have to consider namespace issues when we name them.

> I agree that we need documentation explaining how to use it.  Should
> we write a init-d-script manual page, or just a README?  I suspect a
> manual page is the best option.

I'd say manpage plus comments throughout the code and the skeleton.

> We can discuss more in #pkg-sysvinit on irc.debian.org, if you
> like. :)

e-mail is better while at work, because there is no risk I will just
"disappear" because of a meeting or because my ssh tunnel decided to
collapse and not come back up again for a while :)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh