[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Steve Langasek <vorlon@debian.org> writes:

> I think this should all go in the lsb-base package (bug #661109).
> That's already a "standard" shell library for init scripts, which
> includes lots of functions that aren't part of the LSB standard; I don't
> see a good reason to contribute to a proliferation of shell libraries
> here.

Agreed.

Ideally, we'd be able to refer to that in Policy, at least informatively.
(In general, I like for Policy to spell out what actually has to be done
technically rather than just saying "go use this package," but we can
advise using the package as well.)

> As for making it generic, while I think there should be a similar
> function for systemd, there needs to be some way for the init script to
> indicate which init systems the package actually supports natively; we
> wouldn't want ignore_if_not_sysvinit() for instance.

Good point.

> It also rubs me the wrong way to have the shell library exiting directly
> from the init script.  I'd really prefer an interface such as
> init_is_upstart() which leaves it open for the init script to handle
> some of the mentioned corner cases - in particular, allowing for
> action=stop to DTRT at all points during an upgrade.

Also a good point.  Exits inside libraries always have a bad odor.

However, what might argue for having multiple interfaces is Michael's
point about wanting a shell library that just forwards the actions to the
underlying init system.  In that case, you're going to always want to skip
the rest of the script, but you don't want init_is_upstart() as the
interface.

Maybe something like:

    init_is_upstart && { forward_to_upstart; exit $?; }
    init_is_systemd && { forward_to_systemd; exit $?; }

as the normal pattern for most init scripts, with the possibility left
open to do something more complex?

> Well, in the corner case of a package which calls 'invoke-rc.d restart'
> in postinst, and upstart is running and we're upgrading to the first
> version of the package which supports upstart, I see two options:

>  - have the new version of the package call 'invoke-rc.d stop' in the
>    preinst (before the upstart job is unpacked) so that the service is
>    stopped via the init script.

>  - have the new version of the package call '/etc/init.d/$service stop'
>    explicitly in the postinst, since invoke-rc.d will now be looking at the
>    upstart job instead.

> I prefer the former because it respects policy's existing guidance about
> not calling init scripts directly, but it also leaves a larger window
> when the service will be down on upgrade - and the services that have
> bothered to use 'restart' in the postinst usually do so to prevent
> exactly this.

I think we would have to do the former since, otherwise, wouldn't there be
two copies of the daemon running at the same time?  (Or, more likely, the
second wouldn't start, and then we might end up with no copies running
until upstart restarts it?)

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>



Reply to: