<para>Along with the link file <filename>foo.link</filename>, a "drop-in" directory
<filename>foo.link.d/</filename> may exist. All files with the suffix <literal>.conf</literal>
- from this directory will be parsed after the file itself is parsed. This is useful to alter or add
- configuration settings, without having to modify the main configuration file. Each drop-in file
- must have appropriate section headers.</para>
+ from this directory will be merged in the alphanumeric order and parsed after the main file itself
+ has been parsed. This is useful to alter or add configuration settings, without having to modify
+ the main configuration file. Each drop-in file must have appropriate section headers.</para>
<para>In addition to <filename>/etc/systemd/network</filename>, drop-in <literal>.d</literal>
directories can be placed in <filename>/usr/lib/systemd/network</filename> or
<para>Along with the netdev file <filename>foo.netdev</filename>, a "drop-in" directory
<filename>foo.netdev.d/</filename> may exist. All files with the suffix <literal>.conf</literal>
- from this directory will be parsed after the file itself is parsed. This is useful to alter or
- add configuration settings, without having to modify the main configuration file. Each drop-in
- file must have appropriate section headers.</para>
+ from this directory will be merged in the alphanumeric order and parsed after the main file itself
+ has been parsed. This is useful to alter or add configuration settings, without having to modify
+ the main configuration file. Each drop-in file must have appropriate section headers.</para>
<para>In addition to <filename>/etc/systemd/network</filename>, drop-in <literal>.d</literal>
directories can be placed in <filename>/usr/lib/systemd/network</filename> or
<para>Along with the network file <filename>foo.network</filename>, a "drop-in" directory
<filename>foo.network.d/</filename> may exist. All files with the suffix
- <literal>.conf</literal> from this directory will be parsed after the file itself is
- parsed. This is useful to alter or add configuration settings, without having to modify the main
- configuration file. Each drop-in file must have appropriate section headers.</para>
+ <literal>.conf</literal> from this directory will be merged in the alphanumeric order and parsed
+ after the main file itself has been parsed. This is useful to alter or add configuration settings,
+ without having to modify the main configuration file. Each drop-in file must have appropriate
+ section headers.</para>
<para>In addition to <filename>/etc/systemd/network</filename>, drop-in <literal>.d</literal>
directories can be placed in <filename>/usr/lib/systemd/network</filename> or
<citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
<para>Along with a unit file <filename>foo.service</filename>, a "drop-in" directory
- <filename>foo.service.d/</filename> may exist. All files with the suffix <literal>.conf</literal> from this
- directory will be parsed after the unit file itself is parsed. This is useful to alter or add configuration
- settings for a unit, without having to modify unit files. Drop-in files must contain appropriate section
- headers. For instantiated units, this logic will first look for the instance <literal>.d/</literal> subdirectory
- (e.g. <literal>foo@bar.service.d/</literal>) and read its <literal>.conf</literal> files, followed by the template
- <literal>.d/</literal> subdirectory (e.g. <literal>foo@.service.d/</literal>) and the <literal>.conf</literal>
- files there. Moreover for unit names containing dashes (<literal>-</literal>), the set of directories generated by
- repeatedly truncating the unit name after all dashes is searched too. Specifically, for a unit name
+ <filename>foo.service.d/</filename> may exist. All files with the suffix
+ <literal>.conf</literal> from this directory will be merged in the alphanumeric order and parsed
+ after the main unit file itself has been parsed. This is useful to alter or add configuration
+ settings for a unit, without having to modify unit files. Each drop-in file must contain appropriate
+ section headers. For instantiated units, this logic will first look for the instance
+ <literal>.d/</literal> subdirectory (e.g. <literal>foo@bar.service.d/</literal>) and read its
+ <literal>.conf</literal> files, followed by the template <literal>.d/</literal> subdirectory (e.g.
+ <literal>foo@.service.d/</literal>) and the <literal>.conf</literal> files there. Moreover for unit
+ names containing dashes (<literal>-</literal>), the set of directories generated by repeatedly
+ truncating the unit name after all dashes is searched too. Specifically, for a unit name
<filename>foo-bar-baz.service</filename> not only the regular drop-in directory
<filename>foo-bar-baz.service.d/</filename> is searched but also both <filename>foo-bar-.service.d/</filename> and
<filename>foo-.service.d/</filename>. This is useful for defining common drop-ins for a set of related units, whose
projects / thirdparty / systemd.git / commitdiff
