Like the Description, these are intended to be displayed to the
user, so it makes sense to have them towards the top of the file
before all the information that systemd will parse to calculate
dependencies.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Hypervisors are referred to by their user-facing name rather
than the name of their libvirt driver, the monolithic daemon is
explicitly referred to as legacy, and a consistent format is
used throughout.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Requires/Wants only tells systemd that the corresponding unit
should be started when the current one is, but that could very
well happen in parallel. For virtlogd/virtlockd, we want the
socket to be already active when the hypervisor driver is
started.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Only the main socket is actually necessary for the service to be
usable.
In the past, we've had security issues that could be exploited via
access to the read-only socket, so a security-minded administrator
might consider disabling all optional sockets. This change makes
such a setup possible.
Note that the services will still try to activate all their
sockets on startup, even if they have been disabled. To make sure
that the optional sockets are never started, they will have to be
masked.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This is the strongest relationship that can be declared between
two units, and causes the service to be terminated immediately
if its main socket disappears. This is the behavior we want.
Note that we don't do the same for the read-only/admin sockets,
because those are not as critical for the core functionality of
services as the main socket it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We want to make sure that, at any given time, we have either the
modular daemons or the monolithic one running, never both. In
order to achieve that, make every single modular unit conflict
with the corresponding libvirtd unit.
We set both Conflicts=libvirtd.unit and After=libvirtd.unit: this
tells systemd that, whenever virtfood.unit and libvirtd.unit are
part of the same transaction, the former should win out.
Thanks to this, if both the modular daemons and the monolithic
one have been enabled because of outdated automation or a simple
mistake of the administrator, the request to start libvirtd at
boot will be ignored and the result will be a regular modular
deployment.
If the request to start libvirtd is made when the modular daemons
are already running, we have no way to prevent systemd from
complying with that request; however, thanks to the way the
conflict relationship has been declared, they will be shut down
cleanly before libvirtd is started. From the user's point of
view, the transition from modular to monolithic will be
completely transparent: it's basically the same scenario as a
regular package upgrade, just with an extra twist.
Note that, while switching from modular to monolithic at runtime
happens automatically, going back requires manual intervention,
i.e. starting all the necessary sockets one by one. That's okay:
the goal here is to prevent misconfiguration and force of habit
to accidentally disrupt a working setup, not to encourage the
scenario. In a correctly configured and managed host, it should
never occur.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
We already use templating to generate sockets, which are all
based off libvirtd's. Push the idea further, and extend it to
cover services as well.
This is more challenging, as the various modular daemons each have
their own needs in terms of what system services needs to be
available before they can be started, which other components of
libvirt they depend on, and so on.
In order to make this sort of per-service tweaks possible, we
introduce a Python script that can merge two systemd units
together. The script is aware of the semantics of systemd's unit
definition format, so it can intelligently merge sections
together.
This generic systemd unit merging mechanism will also supersede
the extremely ad-hoc @deps@ variable, which is currently used in
a single scenario.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
