system/systemd
system/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd synced 2024-07-22 02:34:54 +00:00
Code Issues Actions 5 Packages Projects Releases Wiki Activity

man: mention that drop-in files are merged in alphanumeric order

Browse source 
This addresses the request in https://github.com/systemd/systemd/issues/19467#issuecomment-829332877.
This commit is contained in:
Yu Watanabe 2021-05-20 15:55:06 +09:00 committed by Lennart Poettering
parent f144f6faa9
commit e6655fbe40
4 changed files with 20 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
man/systemd.link.xml
View file

@ -47,9 +47,9 @@
<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

6
man/systemd.netdev.xml
View file

@ -52,9 +52,9 @@
<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

7
man/systemd.network.xml
View file

@ -51,9 +51,10 @@
<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

18
man/systemd.unit.xml
View file

@ -184,14 +184,16 @@
<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