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. SkippingIn 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.
Regards, Jim
Attachment:
signature.asc
Description: PGP signature
