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! -- Andrea Bolognani <e...@kiyuko.org> Resistance is futile, you will be garbage collected.
signature.asc
Description: PGP signature
