[PATCH] remote: Move secrets encryption dependency to a systemd drop-in
From: Arun Menon <armenon@redhat.com> The monolithic libvirtd.service currently has a dependency on virt-secret-init-encryption.service. This causes libvirtd to fail to start on systems where the secret driver is not installed or enabled, as systemd cannot satisfy the Requires= / After= units or the LoadCredentialEncrypted= path. See below, Requires=virt-secret-init-encryption.service After=virt-secret-init-encryption.service LoadCredentialEncrypted=secrets-encryption-key:@localstatedir@/lib/libvirt/secrets/secrets-encryption-key This patch decouples the secrets encryption logic from the main libvirtd service file. It is moved into a new systemd drop-in (50-libvirtd-secret.conf) which is only installed when libvirt is built with secret driver support. The override snippet is added to the daemon-driver-secret package. Fixes: 97758bc9a0b1fccf8c0009308658f1204b113b89 Signed-off-by: Arun Menon <armenon@redhat.com> Fix-Suggested-by: Andrea Bolognani <abologna@redhat.com> --- libvirt.spec.in | 2 ++ src/remote/libvirtd-secret.conf.in | 7 +++++++ src/remote/libvirtd.service.in | 4 ---- src/remote/meson.build | 15 +++++++++++++++ 4 files changed, 24 insertions(+), 4 deletions(-) create mode 100644 src/remote/libvirtd-secret.conf.in diff --git a/libvirt.spec.in b/libvirt.spec.in index 00316a03f2..d840c829d1 100644 --- a/libvirt.spec.in +++ b/libvirt.spec.in @@ -2259,6 +2259,8 @@ exit 0 %{_unitdir}/virtsecretd.socket %{_unitdir}/virtsecretd-ro.socket %{_unitdir}/virtsecretd-admin.socket +%dir %attr(0700, root, root) %{_unitdir}/libvirtd.service.d/ +%{_unitdir}/libvirtd.service.d/50-libvirtd-secret.conf %attr(0755, root, root) %{_sbindir}/virtsecretd %dir %attr(0700, root, root) %{_sysconfdir}/libvirt/secrets/ %dir %attr(0700, root, root) %{_localstatedir}/lib/libvirt/secrets/ diff --git a/src/remote/libvirtd-secret.conf.in b/src/remote/libvirtd-secret.conf.in new file mode 100644 index 0000000000..d64a6cf63e --- /dev/null +++ b/src/remote/libvirtd-secret.conf.in @@ -0,0 +1,7 @@ +[Unit] +Requires=@service@ +After=@service@ + +[Service] +Environment=SECRETS_ENCRYPTION_KEY=%d/secrets-encryption-key +LoadCredentialEncrypted=secrets-encryption-key:@localstatedir@/lib/libvirt/secrets/secrets-encryption-key diff --git a/src/remote/libvirtd.service.in b/src/remote/libvirtd.service.in index 7965010a0a..b0a062e885 100644 --- a/src/remote/libvirtd.service.in +++ b/src/remote/libvirtd.service.in @@ -12,8 +12,6 @@ After=libvirtd.socket After=libvirtd-ro.socket After=libvirtd-admin.socket Requires=virtlogd.socket -Requires=virt-secret-init-encryption.service -After=virt-secret-init-encryption.service Wants=virtlockd.socket After=virtlogd.socket After=virtlockd.socket @@ -31,8 +29,6 @@ Conflicts=xendomains.service Type=notify-reload Environment=LIBVIRTD_ARGS="--timeout 120" EnvironmentFile=-@initconfdir@/libvirtd -Environment=SECRETS_ENCRYPTION_KEY=%d/secrets-encryption-key -LoadCredentialEncrypted=secrets-encryption-key:@localstatedir@/lib/libvirt/secrets/secrets-encryption-key ExecStart=@sbindir@/libvirtd $LIBVIRTD_ARGS ExecReload=/bin/kill -HUP $MAINPID KillMode=process diff --git a/src/remote/meson.build b/src/remote/meson.build index e503263266..f1c521444f 100644 --- a/src/remote/meson.build +++ b/src/remote/meson.build @@ -343,4 +343,19 @@ if conf.has('WITH_SASL') ) endif +# The monolithic libvirt daemon only attempts to load the +# secrets encryption credentials if the secret driver is enabled +if conf.has('WITH_SECRETS') + secret_dropin_conf = configuration_data() + secret_dropin_conf.set('service', 'virt-secret-init-encryption.service') + secret_dropin_conf.set('localstatedir', localstatedir) + + configure_file( + input: 'libvirtd-secret.conf.in', + output: '50-libvirtd-secret.conf', + configuration: secret_dropin_conf, + install_dir: unitdir / 'libvirtd.service.d' + ) +endif + remote_inc_dir = include_directories('.') -- 2.53.0
On Mon, Mar 30, 2026 at 09:44:51PM +0530, Arun Menon via Devel wrote:
The monolithic libvirtd.service currently has a dependency on virt-secret-init-encryption.service. This causes libvirtd to fail to start on systems where the secret driver is not installed or enabled, as systemd cannot satisfy the Requires= / After= units or the LoadCredentialEncrypted= path. See below,
Requires=virt-secret-init-encryption.service After=virt-secret-init-encryption.service LoadCredentialEncrypted=secrets-encryption-key:@localstatedir@/lib/libvirt/secrets/secrets-encryption-key
Slight correction, After= is not really a problem, systemd will happily ignore that.
+++ b/libvirt.spec.in @@ -2259,6 +2259,8 @@ exit 0 %{_unitdir}/virtsecretd.socket %{_unitdir}/virtsecretd-ro.socket %{_unitdir}/virtsecretd-admin.socket +%dir %attr(0700, root, root) %{_unitdir}/libvirtd.service.d/ +%{_unitdir}/libvirtd.service.d/50-libvirtd-secret.conf
0700 is unnecessarily restrictive, make it 0755 to match the unit itself. I looked at the %{_unitdir}/*.d/*.conf files that exist in my local installation and it seems that most use 10 as the sorting number. I don't know if there's any specific guideline for that, but unless you have a good reason to pick 50 I'd say stick with what others are doing. Including word "libvirtd" in the name of the drop-in seems unnecessary too. So I suggest using 10-secret.conf here.
+++ b/src/remote/libvirtd-secret.conf.in @@ -0,0 +1,7 @@ +[Unit] +Requires=@service@ +After=@service@
Using templating for this part feels a bit excessive, we know the name of the unit ahead of time and it's not going to change.
+++ b/src/remote/meson.build +# The monolithic libvirt daemon only attempts to load the +# secrets encryption credentials if the secret driver is enabled +if conf.has('WITH_SECRETS') + secret_dropin_conf = configuration_data() + secret_dropin_conf.set('service', 'virt-secret-init-encryption.service') + secret_dropin_conf.set('localstatedir', localstatedir)
So here you can use the slightly nicer secret_dropin_conf = configuration_data({ 'localstatedir': localstatedir, }) matching most of our uses of configuration_data. Feel free to update how virt_secret_init_encryption_conf is defined too, in a separate patch ;) -- Andrea Bolognani / Red Hat / Virtualization
Hi Andrea, Thanks for the review. On Fri, Apr 03, 2026 at 02:37:13AM -0700, Andrea Bolognani wrote:
On Mon, Mar 30, 2026 at 09:44:51PM +0530, Arun Menon via Devel wrote:
The monolithic libvirtd.service currently has a dependency on virt-secret-init-encryption.service. This causes libvirtd to fail to start on systems where the secret driver is not installed or enabled, as systemd cannot satisfy the Requires= / After= units or the LoadCredentialEncrypted= path. See below,
Requires=virt-secret-init-encryption.service After=virt-secret-init-encryption.service LoadCredentialEncrypted=secrets-encryption-key:@localstatedir@/lib/libvirt/secrets/secrets-encryption-key
Slight correction, After= is not really a problem, systemd will happily ignore that.
+++ b/libvirt.spec.in @@ -2259,6 +2259,8 @@ exit 0 %{_unitdir}/virtsecretd.socket %{_unitdir}/virtsecretd-ro.socket %{_unitdir}/virtsecretd-admin.socket +%dir %attr(0700, root, root) %{_unitdir}/libvirtd.service.d/ +%{_unitdir}/libvirtd.service.d/50-libvirtd-secret.conf
0700 is unnecessarily restrictive, make it 0755 to match the unit itself.
I looked at the %{_unitdir}/*.d/*.conf files that exist in my local installation and it seems that most use 10 as the sorting number. I don't know if there's any specific guideline for that, but unless you have a good reason to pick 50 I'd say stick with what others are doing. Including word "libvirtd" in the name of the drop-in seems unnecessary too. So I suggest using 10-secret.conf here.
Yes, I see now. Package drop-ins should not accidentally override the ones defined by the user. Thanks. https://www.freedesktop.org/software/systemd/man/latest/systemd-system.conf....
+++ b/src/remote/libvirtd-secret.conf.in @@ -0,0 +1,7 @@ +[Unit] +Requires=@service@ +After=@service@
Using templating for this part feels a bit excessive, we know the name of the unit ahead of time and it's not going to change.
+++ b/src/remote/meson.build +# The monolithic libvirt daemon only attempts to load the +# secrets encryption credentials if the secret driver is enabled +if conf.has('WITH_SECRETS') + secret_dropin_conf = configuration_data() + secret_dropin_conf.set('service', 'virt-secret-init-encryption.service') + secret_dropin_conf.set('localstatedir', localstatedir)
So here you can use the slightly nicer
secret_dropin_conf = configuration_data({ 'localstatedir': localstatedir, })
Yes.
matching most of our uses of configuration_data. Feel free to update how virt_secret_init_encryption_conf is defined too, in a separate patch ;)
I have incorporated all the feedback in v2 of this series.
-- Andrea Bolognani / Red Hat / Virtualization
Regards, Arun Menon
participants (2)
-
Andrea Bolognani -
Arun Menon