[Pkg-xen-devel] Bug#821254: systemd[1]: xendomains.service start operation timed out.

[Hans van Kranenburg]

Hi,

On 2/2/19 11:49 PM, Andy Smith wrote:
> 
> On Sat, Feb 02, 2019 at 11:24:36PM +0100, Hans van Kranenburg wrote:
>> When working on actually shipping systemd units we'd really need
>> to have a group of users that want to actively help testing
>> everything. Downgrade, upgrade, try to break it etc...
> 
> I actually ended up going from Debian-packaged 4.4.x to Mark Pryor's
> Debian packages because I needed to upgrade version and patch some
> XSAs during embargo. At the time there wasn't much going on with the
> Debian packaging and I didn't feel confident to do it myself, so I
> based things off of Mark's work.
> 
> I used that as a basis for 4.8.x and now 4.10.x packages. Now that
> you are helping with Debian packaging I would like to come back to
> Debian's packages, probably along with an upgrade to buster.
> 
> The systemd stuff from those packages of Mark's did solve this
> problem though. I assume this is upstream content.

Yes, it is, and this made me just realize that this means that you've
been running the end result of what would happen when we would actually
add the systemd stuff to the packaging, already, for quite some time.

That's great, because I guess that already answers most of the "will
these things do the right thing out of the box?" uncertainty.

> I think in 4.4 it
> was generating a systemd service from an init script, whereas now
> it's a native systemd service. Here's /lib/systemd/system/xendomains.service:
> 
> [Unit]
> Description=Xendomains - start and stop guests on boot and shutdown
> Requires=proc-xen.mount xenstored.service
> After=proc-xen.mount xenstored.service xenconsoled.service
> xen-init-dom0.service
> After=network-online.target
> After=remote-fs.target
> ConditionPathExists=/proc/xen/capabilities
> Conflicts=libvirtd.service
> 
> [Service]
> Type=oneshot
> RemainAfterExit=true
> ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities
> ExecStart=-/usr/lib/xen-4.10/bin/xendomains start
> ExecStop=/usr/lib/xen-4.10/bin/xendomains stop
> ExecReload=/usr/lib/xen-4.10/bin/xendomains restart
> 
> [Install]
> WantedBy=multi-user.target

Yup,
https://salsa.debian.org/xen-team/debian-xen/blob/master/tools/hotplug/Linux/systemd/xendomains.service.in

> Those packages came from:
> 
> http://107.185.106.30/xen/debian/stretch-nmu/4ax/
> 
> (plus the XSAs published since then)
> 
> Would it be helpful if I installed buster and
> xen-hypervisor-4.11-amd64 and checked how the systemd unit files
> cope with trying to start 75 or so domains? If so I will try to find
> some time to try that,

Absolutely.

First option would be to find out who/what decides there should be a 5
minute timeout.

But, other option is to upgrade a box to the buster 4.11 packages and
then just put the systemd things from tools/hotplug/Linux/systemd in
place and test what happens. This might be doable for Buster after all
(...there's also 22 other items still on the TODO).

TBH, I'm not an expert at all in this area, I never figured out yet how
all these systemd<->init-script compatibility layers work yet.

Hans