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

Bug#790949: conditional-restart from postinst and related scripts of plugin packages



Hello,

On Fri, Jul 03, 2015 at 11:22:41AM +0200, Daniel Pocock wrote:
> Package: debian-policy
> Severity: important
> 
> Some of this has been discussed in other bugs such as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=60979
> requesting an init script action for restart-only-if-running

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181123

> 
> Consider the following:
> 
> - package foo provides a daemon
> - package foo-plugin-bar provides the 'bar' plugin for 'foo'
> 
> How should the foo-plugin-bar postrm work?

My suggestion is that any package which provides a plugin interface
also provide a dpkg triggers interface that other packages
who ships plugins can interact via.

That way the main package decides what the relevant action is
for a given activated trigger.

(See eg. src:rygel for a packaging example using triggers for plugins.)

> 
> Should it restart foo?

Likely no, never.

(That would mean a new service could get started just because a
plugin happened to be installed.)

> 
> Should it do a conditional restart?

Likely yes, normally.

(Some services might have other better ways to pick up new plugins.)

> 
> During dist-upgrade, can anything be done to ensure the service is not
> started by mistake by one of the postinst scripts until the other
> package has also been upgraded?

Well, bugs may always happen I guess..... but also the previously
suggested trigger solution should help here by centralizing the
implementation in one place rather than spreading/duplicating it
over many packages.

> 
> In the policy manual, s9.3.3.2 "Running initscripts", it is suggested to
> use:
> 
>      	if which invoke-rc.d >/dev/null 2>&1; then
>      		invoke-rc.d package <action>
>      	else
>      		/etc/init.d/package <action>
>      	fi

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833177

> 
> 
> Could it be better to give a second example, how to restart only if
> already running:
> 
>      	if which invoke-rc.d >/dev/null 2>&1; then
>      		invoke-rc.d status package >/dev/null 2>&1 && \

                            ^^^^^^^^^^^^^ wrong order.

>                       invoke-rc.d package restart
>      	else
>      		/etc/init.d/package restart

(Direct init script invokations is BAD! Again, see #833177)

>      	fi
>         # whatever happened, return success:
>         true

Again see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181123

The LSB standard and systemctl variant of this is the 'try-restart'
action. Nothing in current debian policy should disallow you from
using it in your init scripts. Reinventing this interface isn't
really useful. Also, you might be tempted to say that try-reload is only
optional in LSB, not mentioned in debian policy and might not be
available (sure, but if you need it you should add it!) but
then again your suggestion also relies on an action that's not
guaranteed to be available -> status.

> 
> 
> Plugin packages, such as foo-plugin-bar, may want to use this second
> example or some variation of it instead.
> 

The content of this bug report is either:

 a/ already covered by #181123 or #833177
 b/ implementation specific to the daemon providing the plugin interface

Given plugin interfaces are very much custom made I doubt anyone
would suggest mandating a single unified implementation in
Debian policy (which would likely make all existing debian packages
of things providing plugin interfaces RC-buggy at once).

I'm thus not very sure what is being asked to be added to policy?

Which already established pattern in the debian archive is it
that should be recorded in policy?


If it where up to me I'd say this bug report should simply be closed:
 - for the a/ case it's mostly a duplicate of #181123 (and conflict
   against the other).
 - for the b/ case it seems more like a wonfix bug.

This all seems more like something that could be better described on
a wiki.debian.org page discussing plugin strategies and matching debian
packaging strategies plus links to example packages to look at.

Regards,
Andreas Henriksson


Reply to: