Bug#591791: [PATCH] Document generic and upstart-specific init-system requirements

[Jonathan Nieder <jrnieder@gmail.com>]

Hi Michael,

Michael Biebl wrote:

> As I've already mentioned before, I don't like the approach, that any
> init script should use something like:
>
>> if [ "$1" = start ] && which initctl && initctl version | grep -q upstart
>> then
>>	exit 1
>> fi
>
> It seems much more sensible to me, to move all this logic into a
> separate shell library

Would this shell library be four lines?  What package provides it?
Would it be something that can be used in init scripts shared with
other distros (like the above can)?  Would it be enough to provide
such a shell library and encourage people to use it, or should policy
mandate its use to prepare for the shell library to change in some
appropriate way in the future?

By the way, the above example writes the path to initctl to the
terminal when it is present, which I imagine is not intended.

[...]
> Also, the proposal looks underspecified to me: What happens for other
> actions, like stop/restart/reload/force-reload?

Yes, I agree.  The example should be corrected to prevent the daemon
from being started by the restart and force-reload actions.

> What happens in maintainers scripts that call invoke-rc.d service start?
> Will they now suddenly all fail?

According to the proposal,

	implementations of "invoke-rc.d" must detect when upstart is
	running and when an upstart job with the same name as an init
	script is present, and perform the requested action using the
	upstart job instead of the init script.

> How will "service" behave?

Doesn't seem like a matter for policy unless packages need to use
"service" directly in some circumstance, but if I remember correctly
then upstart overrides the "service" command.

Hope that helps,
Jonathan