Bug#851654: Prerm maintainer script unconditionally stops xend/xenconsoled
reassign 851654 src:xen thanks Hm! I think this is the same one that I've been observing during upgrade tests from 4.8 -> 4.11 and 4.10 -> 4.11. In my IRC logs I can find myself complaining about xenconsoled that's suddenly gone multiple times during 2018. I didn't manage to track this issue down yet. The IRC logs contain some links to expired pastebin entries. :| Also, in some cases xenconsoled just got shut down during the night, during some systemd reload whatever was happening. I suspect more users are going to run into this issue when upgrading to Buster. Hans
Bug#851654: Prerm maintainer script unconditionally stops xend/xenconsoled
On Tue, Jan 17, 2017 at 14:45 +, 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 4096R/CAF14EFC 081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC signature.asc Description: PGP signature
Bug#851654: Prerm maintainer script unconditionally stops xend/xenconsoled
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.
Bug#851654: Prerm maintainer script unconditionally stops xend/xenconsoled
Hi Ian,
On Tue, Jan 17, 2017 at 10:58 +, 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
4096R/CAF14EFC
081C B7CD FF04 2BA9 94EA 36B2 8B7F 7D30 CAF1 4EFC
signature.asc
Description: PGP signature
Bug#851654: Prerm maintainer script unconditionally stops xend/xenconsoled
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.
Hi. In recent versions of Xen, xend is gone. So that part of the
problem is too.
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.
Does that make sense ?
Ian.
Bug#851654: Prerm maintainer script unconditionally stops xend/xenconsoled
Package: xen-utils-4.4 Severity: normal Dear Maintainer, the xen-utils-4.4 and xen-utils-4.1 prerm maintainer scripts contain the following code snippet: remove|upgrade) update-alternatives --remove xen-default /usr/lib/xen-4.4 if [ -x "/etc/init.d/xen" ]; then invoke-rc.d xen stop || exit $? fi ;; which, in conjunction with the postinst script triggers a xend and xenconsoled restart that relies on both maintainer scripts being executed. We triggered a xen stop by removing obsolete xen-utils-4.1 packages while already using xen-utils-4.4. Can you think of a way to implement the restart and stop more robustly in that the stop and start actions are performed atomically or the service shipped in the unversioned xen-utils-common is not stopped if it has been started by the maintainer script of a different (newer) xen-utils-X.Y package? -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf-8, LC_CTYPE=en_GB.utf-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
