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 <cales...@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.servicedh_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.
OpenPGP_signature.asc
Description: OpenPGP digital signature
