From 8f6e28876538d5b9073725ba907add1f9f647c9f Mon Sep 17 00:00:00 2001 From: Peter Morrow Date: Mon, 7 Jun 2021 13:05:06 +0100 Subject: [PATCH] man: add details on overriding top level drop-ins When using top level drop-ins it isn't immediately obvious that one can make use of symlinking to disable a top-level drop in for a specific unit. Signed-off-by: Peter Morrow (cherry picked from commit 90a404f5d490eb4981851966f6a01f210fd5eb0d) --- man/systemd.unit.xml | 66 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 62 insertions(+), 4 deletions(-) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index c5a2c441c7..47cd73616b 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -225,10 +225,12 @@ where type may be e.g. service or socket, that allows altering or adding to the settings of all corresponding unit files on the system. The formatting and precedence of applying drop-in configurations follow what is defined above. - Configurations in type.d/ have the lowest precedence - compared to settings in the name specific override directories. So the contents of - foo-.service.d/10-override.conf would override - service.d/10-override.conf. + Files in type.d/ have lower precedence compared + to files in name-specific override directories. The usual rules apply: multiple drop-in files + with different names are applied in lexicographic order, regardless of which of the directories + they reside in, so a file in type.d/ applies + to a unit only if there are no drop-ins or masks with that name in directories with higher + precedence. See Examples. Note that while systemd offers a flexible dependency system between units it is recommended to use this functionality only @@ -2158,6 +2160,62 @@ PrivateTmp=yes to override the entire unit. + + + Top level drop-ins with template units + + Top level drop-ins can be used to change some aspect of all units + of a particular type. For example by creating the + /etc/systemd/system/service.d + directory with a drop-in file, the contents of the drop-in file can be + applied to all service units. We can take this further by having the + top-level drop-in instantiate a secondary helper unit. Consider for + example the following set of units and drop-in files where we install + an OnFailure dependency for all service units. + + + /etc/systemd/system/failure-handler@.service: + + [Unit] +Description=My failure handler for %i + +[Service] +Type=oneshot +# Perform some special action for when %i exits unexpectedly. +ExecStart=/usr/sbin/myfailurehandler %i + + + + We can then add an instance of the + failure-handler@.service as an + OnFailure= dependency for all service units. + + + /etc/systemd/system/service.d/10-all.conf: + + [Unit] +OnFailure=failure-handler@%n.service + + + Now, after running systemctl daemon-reload all + services will have acquired an OnFailure= dependency on + failure-handler@%n.service. The + template instance units will also have gained the dependency which results + in the creation of a recursive dependency chain. We can break the chain by + disabling the drop-in for the template instance units via a symlink to + /dev/null: + + +mkdir /etc/systemd/system/failure-handler@.service.d +ln -s /dev/null /etc/systemd/system/failure-handler@.service.d/10-all.conf +systemctl daemon-reload + + + This ensures that if a failure-handler@.service instance fails it will not trigger an instance named + failure-handler@failure-handler.service.service. + + + -- 2.25.1