Dear devs,
I still consider this issue a bug. Actually, I think the 'kill all qemu
processes' way does not solve any issues that might arise during an
upgrade, even it may cause more trouble. If that is a real concert, a
preinst script might check for running qemu processes, and break if it
founds one. I myself am not real familiar with xen internals, why is a
dedicated qemu process needed for dom0, but for the init script it seems
to be enough to just kill that one only, not all.
I do not understand fully the involved code, in qemu_stop_real() the
script kills the qemu process for dom0 with a known pid in pidfile, and if
it succeeds will kill any other qemu processes also. Is this the intent?
Regards,
Kojedzinszky Richárd
Euronet Magyarorszag Informatika Zrt.
On Mon, 18 Dec 2017, Kojedzinszky Richárd wrote:
Date: Mon, 18 Dec 2017 08:41:06 +0100 (CET)
From: Kojedzinszky Richárd <kojedzinszky.rich...@euronetrt.hu>
To: Hans van Kranenburg <h...@knorrie.org>
Cc: 879...@bugs.debian.org
Subject: Re: xen-utils-common: /etc/init.d/xen restart kills running domU qemu
processes
Dear Hans,
Thanks for your reply. Actually, the problem is that the script kills ALL
qemu processes, not only those attached to xen domU domains. I think that is
a problem.
Would that be nice that a bash upgrade would kill all running bash processes?
And also, in earlier debian releases, this was not the case, I could upgrade
the xen-common package without any issues. Of course, a whole xen
(hypervisor) upgrade might need a reboot, but just a xen-common upgrade might
not. Right now it seems to me it breaks thing more than it helps.
Regards,
Kojedzinszky Richárd
Euronet Magyarorszag Informatika Zrt.
On Sun, 17 Dec 2017, Hans van Kranenburg wrote:
Date: Sun, 17 Dec 2017 20:08:37 +0100
From: Hans van Kranenburg <h...@knorrie.org>
To: 879...@bugs.debian.org,
Richard Kojedzinszky <kojedzinszky.rich...@euronetrt.hu>
Subject: Re: xen-utils-common: /etc/init.d/xen restart kills running domU
qemu
processes
Hi Richard,
it's recommended to only actually upgrade xen packages just before you
want to reboot the system, and when you already stopped all domUs.
This is e.g. a similar situation to upgrading the openvswitch package,
which will also restart processes and mess up all network interfaces of
running domUs.
For unattended-updates, you can just stuff "xen" inside your
Unattended-Upgrade::Package-Blacklist, or if you're not using that you
can put all xen related packages on hold manually and only forcibly
include them to be upgraded just before the reboot.
Upgrading the xen packages while domUs are running can result in a wide
range of scenarios which will cause problems. Solving all of those would
require more work and adding far more complexity to the packages than
there's programmers and testers (and hardware to test all scenarios etc)
available in the Debian project to make that happen currently.
Hans
