diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml index 1f9f071b94a..585b924e3d9 100644 --- a/man/systemd.netdev.xml +++ b/man/systemd.netdev.xml @@ -58,31 +58,38 @@ systemd-networkd8. - Virtual Network Device files must have the extension - .netdev; other extensions are ignored. - Virtual network devices are created as soon as networkd is - started. If a netdev with the specified name already exists, - networkd will use that as-is rather than create its own. Note that - the settings of the pre-existing netdev will not be changed by + The main Virtual Network Device file must have the extension .netdev; + other extensions are ignored. Virtual network devices are created as soon as networkd is + started. If a netdev with the specified name already exists, networkd will use that as-is rather + than create its own. Note that the settings of the pre-existing netdev will not be changed by networkd. - The .netdev files are read from the - files located in the system network directory - /usr/lib/systemd/network, the volatile - runtime network directory - /run/systemd/network and the local - administration network directory - /etc/systemd/network. All configuration files - are collectively sorted and processed in lexical order, regardless - of the directories in which they live. However, files with - identical filenames replace each other. Files in - /etc have the highest priority, files in - /run take precedence over files with the same - name in /usr/lib. This can be used to - override a system-supplied configuration file with a local file if - needed. As a special case, an empty file (file size 0) or symlink - with the same name pointing to /dev/null - disables the configuration file entirely (it is "masked"). + The .netdev files are read from the files located in the system + network directory /usr/lib/systemd/network, the volatile runtime network + directory /run/systemd/network and the local administration network + directory /etc/systemd/network. All configuration files are collectively + sorted and processed in lexical order, regardless of the directories in which they live. + However, files with identical filenames replace each other. Files in /etc + have the highest priority, files in /run take precedence over files with + the same name in /usr/lib. This can be used to override a system-supplied + configuration file with a local file if needed. As a special case, an empty file (file size 0) + or symlink with the same name pointing to /dev/null disables the + configuration file entirely (it is "masked"). + + Along with the netdev file foo.netdev, a "drop-in" directory + foo.netdev.d/ may exist. All files with the suffix .conf + 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. + + In addition to /etc/systemd/network, drop-in .d + directories can be placed in /usr/lib/systemd/network or + /run/systemd/network directories. Drop-in files in + /etc take precedence over those in /run which in turn + take precedence over those in /usr/lib. Drop-in files under any of these + directories take precedence over the main netdev file wherever located. (Of course, since + /run is temporary and /usr/lib is for vendors, it is + unlikely drop-ins should be used in either of those places.) diff --git a/man/systemd.network.xml b/man/systemd.network.xml index c332cd7bdc9..eb7d441842e 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -58,31 +58,40 @@ systemd-networkd8. - Network files must have the extension - .network; other extensions are ignored. - Networks are applied to links whenever the links appear. + The main network file must have the extension .network; other + extensions are ignored. Networks are applied to links whenever the links appear. - The .network files are read from the - files located in the system network directory - /usr/lib/systemd/network, the volatile - runtime network directory - /run/systemd/network and the local - administration network directory - /etc/systemd/network. All configuration files - are collectively sorted and processed in lexical order, regardless - of the directories in which they live. However, files with - identical filenames replace each other. Files in - /etc have the highest priority, files in - /run take precedence over files with the same - name in /usr/lib. This can be used to - override a system-supplied configuration file with a local file if - needed. As a special case, an empty file (file size 0) or symlink - with the same name pointing to /dev/null - disables the configuration file entirely (it is "masked"). + The .network files are read from the files located in the system + network directory /usr/lib/systemd/network, the volatile runtime network + directory /run/systemd/network and the local administration network + directory /etc/systemd/network. All configuration files are collectively + sorted and processed in lexical order, regardless of the directories in which they live. + However, files with identical filenames replace each other. Files in /etc + have the highest priority, files in /run take precedence over files with + the same name in /usr/lib. This can be used to override a system-supplied + configuration file with a local file if needed. As a special case, an empty file (file size 0) + or symlink with the same name pointing to /dev/null disables the + configuration file entirely (it is "masked"). - Note that an interface without any static IPv6 addresses configured, and neither DHCPv6 nor IPv6LL enabled, - shall be considered to have no IPv6 support. IPv6 will be automatically disabled for that interface by writing "1" - to /proc/sys/net/ipv6/conf/ifname/disable_ipv6. + Along with the network file foo.network, a "drop-in" directory + foo.network.d/ may exist. All files with the suffix + .conf 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. + + In addition to /etc/systemd/network, drop-in .d + directories can be placed in /usr/lib/systemd/network or + /run/systemd/network directories. Drop-in files in + /etc take precedence over those in /run which in turn + take precedence over those in /usr/lib. Drop-in files under any of these + directories take precedence over the main netdev file wherever located. (Of course, since + /run is temporary and /usr/lib is for vendors, it is + unlikely drop-ins should be used in either of those places.) + + Note that an interface without any static IPv6 addresses configured, and neither DHCPv6 + nor IPv6LL enabled, shall be considered to have no IPv6 support. IPv6 will be automatically + disabled for that interface by writing "1" to + /proc/sys/net/ipv6/conf/ifname/disable_ipv6. diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index f818e772a98..9778283fec5 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -144,71 +144,71 @@ and are equivalent. - Time span values encoded in unit files can be written in various formats. A stand-alone number specifies a - time in seconds. If suffixed with a time unit, the unit is honored. A concatenation of multiple values with units - is supported, in which case the values are added up. Example: 50 refers to 50 seconds; - 2min 200ms refers to 2 minutes and 200 milliseconds, i.e. 120200 ms. The following time units - are understood: s, min, h, d, + Time span values encoded in unit files can be written in various formats. A stand-alone + number specifies a time in seconds. If suffixed with a time unit, the unit is honored. A + concatenation of multiple values with units is supported, in which case the values are added + up. Example: 50 refers to 50 seconds; 2min 200ms refers to + 2 minutes and 200 milliseconds, i.e. 120200 ms. The following time units are understood: + s, min, h, d, w, ms, us. For details see systemd.time7. - Empty lines and lines starting with # or ; are ignored. This may be - used for commenting. Lines ending in a backslash are concatenated with the following line while reading and the - backslash is replaced by a space character. This may be used to wrap long lines. + Empty lines and lines starting with # or ; are + ignored. This may be used for commenting. Lines ending in a backslash are concatenated with the + following line while reading and the backslash is replaced by a space character. This may be + used to wrap long lines. - Units can be aliased (have an alternative name), by creating a symlink from the new name to the existing name - in one of the unit search paths. For example, systemd-networkd.service has the alias - dbus-org.freedesktop.network1.service, created during installation as the symlink - /usr/lib/systemd/system/dbus-org.freedesktop.network1.service. In addition, unit files may - specify aliases through the Alias= directive in the [Install] section; those aliases are only - effective when the unit is enabled. When the unit is enabled, symlinks will be created for those names, and removed - when the unit is disabled. For example, reboot.target specifies - Alias=ctrl-alt-del.target, so when enabled it will be invoked whenever CTRL+ALT+DEL is - pressed. Alias names may be used in commands like enable, disable, - start, stop, status, …, and in unit dependency directives - Wants=, Requires=, Before=, After=, …, - with the limitation that aliases specified through Alias= are only effective when the unit is - enabled. Aliases cannot be used with the preset command. + Units can be aliased (have an alternative name), by creating a symlink from the new name + to the existing name in one of the unit search paths. For example, + systemd-networkd.service has the alias + dbus-org.freedesktop.network1.service, created during installation as the + symlink /usr/lib/systemd/system/dbus-org.freedesktop.network1.service. In + addition, unit files may specify aliases through the Alias= directive in the + [Install] section; those aliases are only effective when the unit is enabled. When the unit is + enabled, symlinks will be created for those names, and removed when the unit is disabled. For + example, reboot.target specifies + Alias=ctrl-alt-del.target, so when enabled it will be invoked whenever + CTRL+ALT+DEL is pressed. Alias names may be used in commands like enable, + disable, start, stop, + status, …, and in unit dependency directives Wants=, + Requires=, Before=, After=, …, with the + limitation that aliases specified through Alias= are only effective when the + unit is enabled. Aliases cannot be used with the preset command. - Along with a unit file foo.service, the - directory foo.service.wants/ may exist. All - unit files symlinked from such a directory are implicitly added as - dependencies of type Wants= to the unit. This - is useful to hook units into the start-up of other units, without - having to modify their unit files. For details about the semantics - of Wants=, see below. The preferred way to - create symlinks in the .wants/ directory of a - unit file is with the enable command of the + Along with a unit file foo.service, the directory + foo.service.wants/ may exist. All unit files symlinked from such a + directory are implicitly added as dependencies of type Wants= to the unit. + This is useful to hook units into the start-up of other units, without having to modify their + unit files. For details about the semantics of Wants=, see below. The + preferred way to create symlinks in the .wants/ directory of a unit file is + with the enable command of the systemctl1 - tool which reads information from the [Install] section of unit - files (see below). A similar functionality exists for - Requires= type dependencies as well, the - directory suffix is .requires/ in this - case. + tool which reads information from the [Install] section of unit files (see below). A similar + functionality exists for Requires= type dependencies as well, the directory + suffix is .requires/ in this case. Along with a unit file foo.service, a "drop-in" directory - foo.service.d/ may exist. All files with the suffix .conf from this - directory will be parsed after the file itself is parsed. This is useful to alter or add configuration settings for - a unit, without having to modify unit files. Each drop-in file must have appropriate section headers. Note that for - instantiated units, this logic will first look for the instance .d/ subdirectory and read its - .conf files, followed by the template .d/ subdirectory and the - .conf files there. Also note that settings from the [Install] section are not - honoured in drop-in unit files, and have no effect. + foo.service.d/ may exist. All files with the suffix + .conf from this directory will be parsed after the file itself is + parsed. This is useful to alter or add configuration settings for a unit, without having to + modify unit files. Each drop-in file must have appropriate section headers. Note that for + instantiated units, this logic will first look for the instance .d/ + subdirectory and read its .conf files, followed by the template + .d/ subdirectory and the .conf files there. Also note that + settings from the [Install] section are not honoured in drop-in unit files, + and have no effect. - In addition to /etc/systemd/system, - the drop-in .conf files for system services - can be placed in /usr/lib/systemd/system or - /run/systemd/system directories. Drop-in - files in /etc take precedence over those in - /run which in turn take precedence over - those in /usr/lib. Drop-in files under any of - these directories take precedence over unit files wherever located. - (Of course, since /run is temporary and - /usr/lib is for vendors, it is unlikely - drop-ins should be used in either of those places.) - + In addition to /etc/systemd/system, the drop-in .d + directories for system services can be placed in /usr/lib/systemd/system or + /run/systemd/system directories. Drop-in files in /etc + take precedence over those in /run which in turn take precedence over those + in /usr/lib. Drop-in files under any of these directories take precedence + over unit files wherever located. (Of course, since /run is temporary and + /usr/lib is for vendors, it is unlikely drop-ins should be used in either + of those places.) + + Some unit names reflect paths existing in the file system namespace. Example: a device unit