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
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>