mirror of
https://github.com/systemd/systemd
synced 2024-07-22 02:34:54 +00:00
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 <pemorrow@linux.microsoft.com>
This commit is contained in:
parent
d477a094e8
commit
90a404f5d4
|
@ -225,10 +225,12 @@
|
|||
where <replaceable>type</replaceable> may be e.g. <literal>service</literal> or <literal>socket</literal>,
|
||||
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 <filename><replaceable>type</replaceable>.d/</filename> have the lowest precedence
|
||||
compared to settings in the name specific override directories. So the contents of
|
||||
<filename>foo-.service.d/10-override.conf</filename> would override
|
||||
<filename>service.d/10-override.conf</filename>.</para>
|
||||
Files in <filename><replaceable>type</replaceable>.d/</filename> 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 <filename><replaceable>type</replaceable>.d/</filename> applies
|
||||
to a unit only if there are no drop-ins or masks with that name in directories with higher
|
||||
precedence. See Examples.</para>
|
||||
|
||||
<para>Note that while systemd offers a flexible dependency system
|
||||
between units it is recommended to use this functionality only
|
||||
|
@ -2201,6 +2203,62 @@ PrivateTmp=yes</programlisting>
|
|||
to override the entire unit.</para>
|
||||
|
||||
</example>
|
||||
|
||||
<example>
|
||||
<title>Top level drop-ins with template units</title>
|
||||
|
||||
<para>Top level drop-ins can be used to change some aspect of all units
|
||||
of a particular type. For example by creating the
|
||||
<filename index='false'>/etc/systemd/system/service.d</filename>
|
||||
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.</para>
|
||||
|
||||
<para>
|
||||
<filename index='false'>/etc/systemd/system/failure-handler@.service</filename>:</para>
|
||||
|
||||
<programlisting>[Unit]
|
||||
Description=My failure handler for %i
|
||||
|
||||
[Service]
|
||||
Type=oneshot
|
||||
# Perform some special action for when %i exits unexpectedly.
|
||||
ExecStart=/usr/sbin/myfailurehandler %i
|
||||
|
||||
</programlisting>
|
||||
|
||||
<para>We can then add an instance of the
|
||||
<filename index='false'>failure-handler@.service</filename> as an
|
||||
<varname>OnFailure=</varname> dependency for all service units.</para>
|
||||
|
||||
<para>
|
||||
<filename index='false'>/etc/systemd/system/service.d/10-all.conf</filename>:</para>
|
||||
|
||||
<programlisting>[Unit]
|
||||
OnFailure=failure-handler@%n.service
|
||||
</programlisting>
|
||||
|
||||
<para>Now, after running <command>systemctl daemon-reload</command> all
|
||||
services will have acquired an <varname>OnFailure=</varname> dependency on
|
||||
<filename index='false'>failure-handler@%n.service</filename>. 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
|
||||
<filename index='false'>/dev/null</filename>:</para>
|
||||
|
||||
<programlisting>
|
||||
<command>mkdir /etc/systemd/system/failure-handler@.service.d</command>
|
||||
<command>ln -s /dev/null /etc/systemd/system/failure-handler@.service.d/10-all.conf</command>
|
||||
<command>systemctl daemon-reload</command>
|
||||
</programlisting>
|
||||
|
||||
<para>This ensures that if a <filename index='false'>failure-handler@.service</filename> instance fails it will not trigger an instance named
|
||||
<filename index='false'>failure-handler@failure-handler.service.service</filename>.</para>
|
||||
|
||||
</example>
|
||||
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
|
Loading…
Reference in a new issue