[Pkg-libvirt-maintainers] Bug#1082939: /usr/bin/deb-systemd-helper: error: unable to read virtlockd.socket

[Michael Biebl]

Am 05.10.24 um 19:51 schrieb Andrea Bolognani:
> On Fri, Oct 04, 2024 at 08:57:36PM +0200, Michael Biebl wrote:
>> On Sat, 28 Sep 2024 18:57:05 +0200 Christoph Anton Mitterer <calestyo at scientia.org> wrote:
>>> Upgrading the package gives:
>>> Setting up libvirt-daemon (10.7.0-3) ...
>>> /usr/bin/deb-systemd-helper: error: unable to read virtlockd.socket
>>> Setting up libvirt-daemon-driver-nwfilter (10.7.0-3) ...
>>
>> I guess the issue here is the following:
>>
>> libvirtd.service:Wants=virtlockd.socket
>> libvirtd.service:After=virtlockd.socket
>> libvirtd.service:Also=virtlockd.socket
>>
>> Especially the Also=virtlockd.socket means, that when enabling
>> libvirtd.service, it is attempted to enable virtlockd.socket as well.
> 
> Correct.
> 
>> You don't have that installed though (as libvirt-daemon does not declare a
>> hard dependency)
> 
> This is intentional.
> 
>>> pn  libvirt-daemon-lock                    <none>
>>
>> My recommendation would be to drop the "Also=virtlockd.socket" line from
>> libvirt.service (and "Also=virtlogd.socket" as well), or upgrade the weak
>> recommends to a depends for both packages.
> 
> The current setup seem to match intentions, with one caveat that I'll
> address below.
> 
> virtlogd and virtlockd are secondary daemons that the primary
> libvirtd daemon might need to delegate some operations to, so it
> makes sense that they'll be enabled/started together with it; at the
> same time, there are scenarios in which it's valid to have just the
> primary daemon, hence why weak dependencies are used both between
> unit files and packages.
> 
> The caveat is that libvirtd.service contains Requires=virtlogd.socket
> without a matching Depends from libvirt-daemon to libvirt-daemon-log.
> This is an obvious bug that needs to be addressed.
> 
> Turning the Recommends from libvirt-daemon to libvirt-daemon-lock
> into a Depends is undesirable, as it would force people to have
> virtlockd installed on their systems even though the vast majority of
> setups don't actually need it. The whole point of moving the various
> drivers and daemons to separate packages was to allow for
> minimalistic, carefully curated installations, so this would
> represent an unwanted step backwards.
> 
> Dropping the Also= lines is undesirable too, as it would require
> users to explicitly care about enabling/disabling virtlogd and
> virtlockd when enabling/disabling libvirtd. With the way things
> currently work, it's enough for users to operate on the primary
> daemon and the secondary ones will come along for the ride. Plus it
> would mean having to diverge from upstream.
> 
> It should be noted that systemd itself is perfectly happy with this
> arrangement: since Wants= and Also= are weak dependencies, the
> corresponding units being missing is not considered a problem. As far
> as I can tell, that doesn't even cause a warning to be logged
> anywhere, much less print out an error message.
> 
> I don't know the internals of deb-systemd-helper very well, but is
> there a chance that we could simply make it as tolerant to this
> scenario as systemd itself is?
> 
> Thanks for looking into this!
> 

/usr/lib/systemd/system/virtlockd-admin.socket:Also=virtlockd.socket

Yet debian/rules uses:

dh_installsystemd -p libvirt-daemon --no-also libvirtd.service
dh_installsystemd -p libvirt-daemon --no-stop-on-upgrade libvirtd.socket 
libvirtd-ro.socket libvirtd-admin.socket

I.e. virtlockd.socket is also referenced from virtlockd-admin.socket but 
the dh_installsystemd line for libvirtd-admin.socket does not contain 
"--no-also", so dh_installsystem will generate maintscript code to 
enable virtlockd.socket in libvirt-daemon.postinst (you can check the 
generated code after a successful build to verify that).

You probably need to more closely inspect which unit file references 
which other unit via Also= and if they are shipped in the same package 
or if not, what packaging relationship they have.


Keep in mind that "--no-also" is currently an undocumented option of 
dh_installsystemd, i.e. not an officially supported feature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-libvirt-maintainers/attachments/20241006/24997bd1/attachment.sig>