On Wed, Jun 14, 2023 at 04:45:06PM -0600, Jim Fehlig wrote:
On 6/9/23 03:05, Andrea Bolognani wrote:On Thu, Jun 08, 2023 at 12:35:45PM -0600, Jim Fehlig wrote:On 6/8/23 08:52, Andrea Bolognani wrote:On Wed, Jun 07, 2023 at 04:31:36PM +0200, Martin Kletzander wrote:+# Since this was split into a different package, a transparent update for the +# virtproxyd units could actually disable an already configured ones +# (e.g. virtproxyd-tls.socket) as %systemd_post runs `systemctl preset` if this +# is an installation (and is skipped on update). So skip this step for those +# that need an extra setup to work since they will most likely not be preset to +# enabled, but that is up to the point of the distribution. +%libvirt_daemon_systemd_post virtproxydIt's actually worse than that: if you are using the monolithic daemon on a distro that uses split daemons by default (e.g. Fedora),Why use the monolithic and split daemons together? Shouldn't we discourage such configuration? :-)Whether to use monlithic or split daemons is ultimately a choice of the local admin. Fedora defaults to split daemons, but switching back to a "classic" monolithic deployment is still a fully supported scenario. Additionally, the current default has been adopted relatively recently, and we have made the explicit decision *not* to migrate existing installations over. So if your OS was originally installed before split daemons had become the default and you've been dutifully upgrading to subsequent Fedora releases without ever reinstalling, then you're also going to be using the monolithic daemon.Basically we need to detect if we're installing the libvirt-daemon-proxy package as part of an upgrade and *not touch anything* if that's the case. I'm not sure how that can be achieved in the context of RPM scriptlets though, or if it's even possible :(It's possible to determine a package install vs upgrade, but IIUC the problem can occur when installing or upgrading libvirt-daemon-proxy. The usual 'if [ $1 -ge 2 ]' for upgrade-only actions wont work in that case.Yeah, exactly: it's easy to detect whether a single package is being upgraded or installed from scratch, but in this case we would need to know whether libvirt-daemon is being upgraded in the scriptlet for libvirt-daemon-proxy, which I don't think is possible.I think we need to know more than whether libvirt-daemon is being upgraded. We need to also know whether it's running, right? Even if libvirt-daemon is being upgraded, it's fine to call %systemd_post on virtproxyd sockets if the libvirtd ones are disabled, right? If this is the case, my idea to use trigger scriptlets doesn't help.Can we somehow enforce that libvirt-daemon is fully configured before libvirt-daemon-proxy? If so, we could create a witness file based on the information we need in libvirt-daemon's %post, look at it in libvirt-daemon-proxy's %post and base our decision on that.What would the witness file indicate? As I understand, it would essentially have to indicate whether libvirtd sockets/service are enabled. If so, couldn't that be done directly in virtproxy post script? Something like the below hack?
We already have some things for this. There is libvirt_daemon_schedule_restart, but that is done in the post phase. What we could do is check the current state (whether libvirtd is running and what is being installed) in %pretrans of the daemon and virtproxyd, save it somewhere similar to libvirt_daemon_schedule_restart and then in %posttrans or %post actually figure out what the new state should be. Does that make sense?
Regards,
Jim
diff --git a/libvirt.spec.in b/libvirt.spec.in
index 1f77cd90b7..c848c70c0c 100644
--- a/libvirt.spec.in
+++ b/libvirt.spec.in
@@ -1592,7 +1592,19 @@ fi
%post daemon-proxy
%if %{with_modular_daemons}
-%libvirt_daemon_systemd_post_inet virtproxyd
+libvirtd_enabled=0
+for unit in -ro.socket .service .socket
+do
+ if systemctl is-enabled libvirtd$unit
+ then
+ libvirtd_enabled=1
+ break
+ fi
+done
+if [ $libvirtd_enabled -eq 0 ]
+then
+ %libvirt_daemon_systemd_post_inet virtproxyd
+fi
%endif
%preun daemon-proxy
Attachment:
signature.asc
Description: PGP signature
