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

I'm still investigating that issue but think the dependency issue is worth
discussing independently.

Jim Fehlig (2):
  libvirt-guests: Remove unused variable 'libvirtd'
  libvirt-guests: Add systemd odering dependency to virtproxyd

 tools/libvirt-guests.service.in | 1 +
 tools/libvirt-guests.sh.in      | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

-- 
2.41.0

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.

>I'm still investigating that issue but think the dependency issue is worth
>discussing independently.
>
>Jim Fehlig (2):
>  libvirt-guests: Remove unused variable 'libvirtd'
>  libvirt-guests: Add systemd odering dependency to virtproxyd
>
> tools/libvirt-guests.service.in | 1 +
> tools/libvirt-guests.sh.in      | 1 -
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
>-- 
>2.41.0
>

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.

Regards,
Jim

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.

>Regards,
>Jim
>

On 8/3/23 05:52, Martin Kletzander wrote:
> 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.

Without virtproxyd. I see the same when using virtproxyd and libvirt built with 
-Dremote_default_mode=legacy.

> 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.

# systemctl list-jobs
JOB  UNIT                   TYPE  STATE
1010 virtqemud.service      start waiting
1009 libvirt-guests.service stop  running

Regards,
Jim