Pkg xen devel - Jan 2017 - Bug#851654: Prerm maintainer script unconditionally stops xend/xenconsoled

Hi Ian,

On Tue, Jan 17, 2017 at 10:58 +0000, Ian Jackson wrote:
> Wolodja Wentland writes ("Bug#851654: Prerm maintainer script
unconditionally
> stops xend/xenconsoled"): > We triggered a xen stop by removing
obsolete
> xen-utils-4.1 packages while already using xen-utils-4.4.
> I think a xenconsoled restart should be harmless, so I think it is
> probably right that the maintainer scripts end up stopping the old
> xenconsoled and starting a new one, at least unless it's going to be
> away for a long time.
It makes perfect sense for them to restart xenconsoled during package upgrades
which the combination of prerm and postinst scripts achieves for upgrades of the
same versioned package. Upgrades of xen-utils-4.{1,4,8} will all stop
xenconsoled during the prerm run and start it again in the postinst run of the
upgraded package.

The problem we encountered, however, was that we removed obsolete packages
(xen-utils-4.1) after the postinst script of a newer one (xen-utils-4.4) had
already started xenconsoled. The prerm script of xen-utils-4.1 thereby stopped a
daemon that was started by the postinst script of xen-utils-4.4 and xenconsoled
was no longer running as a result. If the maintainer scripts of these versioned
packages would only deal with 'their' version this would not happen.
--
Wolodja <debian at babilen5.org>

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20170117/3ee309e6/attachment.sig>

Control: tags -1 confirmed

Wolodja Wentland writes ("Re: Bug#851654: Prerm maintainer script
unconditionally stops xend/xenconsoled"):
> The problem we encountered, however, was that we removed obsolete
> packages (xen-utils-4.1) after the postinst script of a newer one
> (xen-utils-4.4) had already started xenconsoled. The prerm script of
> xen-utils-4.1 thereby stopped a daemon that was started by the
> postinst script of xen-utils-4.4 and xenconsoled was no longer
> running as a result.
Oh, I see.  Yes, that is clearly a bug.
>  If the maintainer scripts of these versioned
> packages would only deal with 'their' version this would not
happen.
I wonder if this is the best approach.  Which of the different coinstallable
packages' xenconsoled actually ends up running depends on the booted
hypervisor, so there should be only one of these sets active at a time.

Ian.

On Tue, Jan 17, 2017 at 14:45 +0000, Ian Jackson wrote:
> >  If the maintainer scripts of these versioned
> > packages would only deal with 'their' version this would not
happen.
> I wonder if this is the best approach.  Which of the different
coinstallable
> packages' xenconsoled actually ends up running depends on the booted
> hypervisor, so there should be only one of these sets active at a time.
That's a very good idea! Would you implement this in the init script shipped
in
xen-utils-common itself or do you think that it would be more appropriate in the
xen-utils maintainer scripts?
--
Wolodja <debian at babilen5.org>

4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20170117/3deca604/attachment.sig>