On Mon, Jul 31, 2023 at 05:06:44PM -0600, Jim Fehlig wrote: > The first patch is trivial. I suppose the second is debatable. If I build > libvirt with -Dremote_default_mode=legacy but deploy modular daemons, > /run/libvirt/libvirt-sock is provided by virtproxyd, which may or may not > be running when libvirt-guests starts/stops. I added an 'After=virtproxyd.socket' > ordering dependency to libvirt-guests, but it hasn't fixed an issue I'm > seeing when using libvirt-guests+virtproxyd > > libvirt-guests.sh[2607]: Can't connect to default. Skipping > In this case the connection should use the legacy mode according to the code.

I think you are running into the same thing as we were in     https://bugzilla.redhat.com/show_bug.cgi?id=1964855 and you want to have virtproxyd.service instead of virtproxyd.socket there.  It's complicated, but look at my commit 59d30adacd1d and comment #7 in the above mentioned bugzilla.

In any case I think in such a scenario you want the libvirt-guests to connect to the particular daemon.  That's the reason I did not modify the virtproxyd in the commit and the reason the socket is not in the service file.

On Wed, Aug 02, 2023 at 01:40:16PM -0600, Jim Fehlig wrote: > On 8/1/23 08:11, Martin Kletzander wrote: >> On Mon, Jul 31, 2023 at 05:06:44PM -0600, Jim Fehlig wrote: >>> The first patch is trivial. I suppose the second is debatable. If I build >>> libvirt with -Dremote_default_mode=legacy but deploy modular daemons, >>> /run/libvirt/libvirt-sock is provided by virtproxyd, which may or may not >>> be running when libvirt-guests starts/stops. I added an >>> 'After=virtproxyd.socket' >>> ordering dependency to libvirt-guests, but it hasn't fixed an issue I'm >>> seeing when using libvirt-guests+virtproxyd >>> >>> libvirt-guests.sh[2607]: Can't connect to default. Skipping >>> >> >> In this case the connection should use the legacy mode according to the >> code. > > Nod. > >> I think you are running into the same thing as we were in >> >>      https://bugzilla.redhat.com/show_bug.cgi?id=1964855 >> >> and you want to have virtproxyd.service instead of virtproxyd.socket >> there.  It's complicated, but look at my commit 59d30adacd1d and comment >> #7 in the above mentioned bugzilla. > > Yes, I see the same problem. Thanks for the pointer! But unless I have something > misconfigured, the suggestions you made to the daemon docs don't work for me. My > setup is a recent openSUSE Tumbleweed with systemd 253.7 and libvirt 9.6.0 built > with -Dremote_default_mode=direct. The unit section of > /etc/systemd/system/libvirt-guests.service contains > > [Unit] > Description=Suspend/Resume Running libvirt Guests > Requires=virt-guest-shutdown.target > After=network.target > After=time-sync.target > After=virtqemud.service > After=virt-guest-shutdown.target > > 'systemctl daemon-reload' executed, virtqemud.service and socket are enabled, > and the socket is active. With the service also active, 'systemctl stop > libvirt-guests.service' works fine. If virtqemud.service is not running, > 'systemctl stop libvirt-guests.service' hangs as described in the bug. Killing > the hung libvirt-guests.sh allows the stop job to complete and start job for > virtqemud.service to begin. So for me it seems the bug still exists when using > the default URI. > >> In any case I think in such a scenario you want the libvirt-guests to >> connect to the particular daemon.  That's the reason I did not modify >> the virtproxyd in the commit and the reason the socket is not in the >> service file. > > Indeed, if I set 'uri_default = "qemu:///system"' in /etc/libvirt/libvirt.conf, > then 'systemctl stop libvirt-guests.service' succeeds even when > virtqemud.service is not active. > And that is with or without virtproxyd?  Can you check the other use case?  I don't have the setup on hand.

Can you also capture the output of `systemctl list-jobs` during the blockage?  Just to see it really is systemd what we're waiting for.