package: systemd

title: org.freedesktop.timedate1(5)

summary: The D\-Bus interface of systemd\-timedated

text:
# org.freedesktop.timedate1(5)

## NAME
org.freedesktop.timedate1 - The D-Bus interface of systemd-timedated

## INTRODUCTION
systemd-timedated.service(8) is a system service that can be used to control the system time and related settings. This page describes the D-Bus interface.

## THE D-BUS API
The service exposes the following interfaces on the bus:

```
node /org/freedesktop/timedate1 {

  interface org.freedesktop.timedate1 {

    methods:

      SetTime(in  x usec_utc,

              in  b relative,

              in  b interactive);

      SetTimezone(in  s timezone,

                  in  b interactive);

      SetLocalRTC(in  b local_rtc,

                  in  b fix_system,

                  in  b interactive);

      SetNTP(in  b use_ntp,

             in  b interactive);

      ListTimezones(out as timezones);

    properties:

      readonly s Timezone = '...';

      readonly b LocalRTC = ...;

      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")

      readonly b CanNTP = ...;

      readonly b NTP = ...;

      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")

      readonly b NTPSynchronized = ...;

      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")

      readonly t TimeUSec = ...;

      @org.freedesktop.DBus.Property.EmitsChangedSignal("false")

      readonly t RTCTimeUSec = ...;

  };

  interface org.freedesktop.DBus.Peer { ... };

  interface org.freedesktop.DBus.Introspectable { ... };

  interface org.freedesktop.DBus.Properties { ... };
};

```

### Methods
Use SetTime() to change the system clock. Pass a value of microseconds since the UNIX epoch (1 Jan 1970 UTC). If relative is true, the passed usec value will be added to the current system time. If it is false, the current system time will be set to the passed usec value. If the system time is set with this method, the RTC will be updated as well.

Use SetTimezone() to set the system timezone. Pass a value like "Europe/Berlin" to set the timezone. Valid timezones are listed in /usr/share/zoneinfo/zone.tab. If the RTC is configured to be maintained in local time, it will be updated accordingly.

Use SetLocalRTC() to control whether the RTC is in local time or UTC. It is strongly recommended to maintain the RTC in UTC. However, some OSes (Windows) maintain the RTC in local time, which might make it necessary to enable this feature. Note that this might create various problems as daylight changes could be missed. If fix_system is "true", the time from the RTC is read again and the system clock is adjusted according to the new setting. If fix_system is "false", the system time is written to the RTC taking the new setting into account. Use fix_system=true in installers and livecds where the RTC is probably more reliable than the system time. Use fix_system=false in configuration UIs that are run during normal operation and where the system clock is probably more reliable than the RTC.

Use SetNTP() to control whether the system clock is synchronized with the network using systemd-timesyncd. This will enable and start or disable and stop the chosen time synchronization service.

ListTimezones() returns a list of time zones known on the local system as an array of names ("["Africa/Abidjan", "Africa/Accra", ..., "UTC"]").

### Properties
Timezone shows the currently configured time zone. LocalRTC shows whether the RTC is configured to use UTC (false), or the local time zone (true). CanNTP shows whether a service to perform time synchronization over the network is available, and NTP shows whether such a service is enabled.

NTPSynchronized shows whether the kernel reports the time as synchronized (c.f. adjtimex(3)). TimeUSec and RTCTimeUSec show the current time on the system and in the RTC. The purpose of those three properties is to allow remote clients to access this information over D-Bus. Local clients can access the information directly.

Whenever the Timezone and LocalRTC settings are changed via the daemon, PropertyChanged signals are sent out to which clients can subscribe.

Note that this service will not inform you about system time changes. Use timerfd(3) with CLOCK_REALTIME and TFD_TIMER_CANCEL_ON_SET for that.

### Security
The interactive boolean parameters can be used to control whether polkit[1] should interactively ask the user for authentication credentials if required.

The polkit action for SetTimezone() is org.freedesktop.timedate1.set-timezone. For SetLocalRTC() it is org.freedesktop.timedate1.set-local-rtc, for SetTime() it is org.freedesktop.timedate1.set-time and for SetNTP() it is org.freedesktop.timedate1.set-ntp. ListTimezones() does not require any privileges.

## EXAMPLES
Example 1. Introspect org.freedesktop.timedate1 on the bus

```
$ gdbus introspect --system \

  --dest org.freedesktop.timedate1 \

  --object-path /org/freedesktop/timedate1

```

## VERSIONING
These D-Bus interfaces follow the usual interface versioning guidelines[2].

## SEE ALSO
More information on how the system clock and RTC interact[3]

## NOTES
1.

polkit

https://www.freedesktop.org/software/polkit/docs/latest/

2.

the usual interface versioning guidelines

http://0pointer.de/blog/projects/versioning-dbus.html

3.

More information on how the system clock and RTC interact

https://lists.freedesktop.org/archives/systemd-devel/2011-May/002526.html


os-release

title: os-release(5)

summary: Operating system identification

text:
# os-release(5)

## NAME
os-release, initrd-release - Operating system identification

## SYNOPSIS
/etc/os-release

/lib/os-release

/usr/lib/os-release

/etc/initrd-release

## DESCRIPTION
The /etc/os-release and /lib/os-release files contain operating system identification data.

The basic file format of os-release is a newline-separated list of environment-like shell-compatible variable assignments. It is possible to source the configuration from shell scripts, however, beyond mere variable assignments, no shell features are supported (this means variable expansion is explicitly not supported), allowing applications to read the file without implementing a shell compatible execution engine. Variable assignment values must be enclosed in double or single quotes if they include spaces, semicolons or other special characters outside of A–Z, a–z, 0–9. Shell special characters ("$", quotes, backslash, backtick) must be escaped with backslashes, following shell style. All strings should be in UTF-8 format, and non-printable characters should not be used. It is not supported to concatenate multiple individually quoted strings. Lines beginning with "#" shall be ignored as comments. Blank lines are permitted and ignored.

The file /etc/os-release takes precedence over /lib/os-release. Applications should check for the former, and exclusively use its data if it exists, and only fall back to /lib/os-release if it is missing. Applications should not read data from both files at the same time. /lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /lib/os-release, to provide compatibility with applications only looking at /etc/. A relative symlink instead of an absolute symlink is necessary to avoid breaking the link in a chroot or initrd environment such as dracut.

os-release contains data that is defined by the operating system vendor and should generally not be changed by the administrator.

As this file only encodes names and identifiers it should not be localized.

The /etc/os-release and /lib/os-release files might be symlinks to other files, but it is important that the file is available from earliest boot on, and hence must be located on the root file system.

For a longer rationale for os-release please refer to the Announcement of /etc/os-release[1].

### /etc/initrd-release
In the initrd[2], /etc/initrd-release plays the same role as os-release in the main system. Additionally, the presence of that file means that the system is in the initrd phase. /etc/os-release should be symlinked to /etc/initrd-release (or vice versa), so programs that only look for /etc/os-release (as described above) work correctly. The rest of this document that talks about os-release should be understood to apply to initrd-release too.

## OPTIONS
The following OS identifications parameters may be set using os-release:

### General information identifying the operating system
NAME=

A string identifying the operating system, without a version component, and suitable for presentation to the user. If not set, a default of "NAME=Linux" may be used. Examples: "NAME=Fedora", "NAME="Debian GNU/Linux"".

ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_" and "-") identifying the operating system, excluding any version information and suitable for processing by scripts or usage in generated filenames. If not set, a default of "ID=linux" may be used. Examples: "ID=fedora", "ID=debian".

ID_LIKE=

A space-separated list of operating system identifiers in the same syntax as the ID= setting. It should list identifiers of operating systems that are closely related to the local operating system in regards to packaging and programming interfaces, for example listing one or more OS identifiers the local OS is a derivative from. An OS should generally only list other OS identifiers it itself is a derivative of, and not any OSes that are derived from it, though symmetric relationships are possible. Build scripts and similar should check this variable if they need to identify the local operating system and the value of ID= is not recognized. Operating systems should be listed in order of how closely the local operating system relates to the listed ones, starting with the closest. This field is optional. Examples: for an operating system with "ID=centos", an assignment of "ID_LIKE="rhel fedora"" would be appropriate. For an operating system with "ID=ubuntu", an assignment of "ID_LIKE=debian" is appropriate.

PRETTY_NAME=

A pretty operating system name in a format suitable for presentation to the user. May or may not contain a release code name or OS version of some kind, as suitable. If not set, a default of "PRETTY_NAME="Linux"" may be used Example: "PRETTY_NAME="Fedora 17 (Beefy Miracle)"".

CPE_NAME=

A CPE name for the operating system, in URI binding syntax, following the Common Platform Enumeration Specification[3] as proposed by the NIST. This field is optional. Example: "CPE_NAME="cpe:/o:fedoraproject:fedora:17""

VARIANT=

A string identifying a specific variant or edition of the operating system suitable for presentation to the user. This field may be used to inform the user that the configuration of this system is subject to a specific divergent set of rules or default configuration settings. This field is optional and may not be implemented on all systems. Examples: "VARIANT="Server Edition"", "VARIANT="Smart Refrigerator Edition"".

Note: this field is for display purposes only. The VARIANT_ID field should be used for making programmatic decisions.

VARIANT_ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_" and "-"), identifying a specific variant or edition of the operating system. This may be interpreted by other packages in order to determine a divergent default configuration. This field is optional and may not be implemented on all systems. Examples: "VARIANT_ID=server", "VARIANT_ID=embedded".

### Information about the version of the operating system
VERSION=

A string identifying the operating system version, excluding any OS name information, possibly including a release code name, and suitable for presentation to the user. This field is optional. Examples: "VERSION=17", "VERSION="17 (Beefy Miracle)"".

VERSION_ID=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, ".", "_" and "-") identifying the operating system version, excluding any OS name information or release code name, and suitable for processing by scripts or usage in generated filenames. This field is optional. Examples: "VERSION_ID=17", "VERSION_ID=11.04".

VERSION_CODENAME=

A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_" and "-") identifying the operating system release code name, excluding any OS name information or release version, and suitable for processing by scripts or usage in generated filenames. This field is optional and may not be implemented on all systems. Examples: "VERSION_CODENAME=buster", "VERSION_CODENAME=xenial".

BUILD_ID=

A string uniquely identifying the system image originally used as the installation base. In most cases, VERSION_ID or IMAGE_ID+IMAGE_VERSION are updated when the entire system image is replaced during an update. BUILD_ID may be used in distributions where the original installation image version is important: VERSION_ID would change during incremental system updates, but BUILD_ID would not. This field is optional. Examples: "BUILD_ID="2013-03-20.3"", "BUILD_ID=201303203".

IMAGE_ID=

A lower-case string (no spaces or other characters outside of 0–9, a–z, ".", "_" and "-"), identifying a specific image of the operating system. This is supposed to be used for environments where OS images are prepared, built, shipped and updated as comprehensive, consistent OS images. This field is optional and may not be implemented on all systems, in particularly not on those that are not managed via images but put together and updated from individual packages and on the local system. Examples: "IMAGE_ID=vendorx-cashier-system", "IMAGE_ID=netbook-image".

IMAGE_VERSION=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, ".", "_" and "-") identifying the OS image version. This is supposed to be used together with IMAGE_ID described above, to discern different versions of the same image. Examples: "IMAGE_VERSION=33", "IMAGE_VERSION=47.1rc1".

To summarize: if the image updates are built and shipped as comprehensive units, IMAGE_ID+IMAGE_VERSION is the best fit. Otherwise, if updates eventually completely replace previously installed contents, as in a typical binary distribution, VERSION_ID should be used to identify major releases of the operating system. BUILD_ID may be used instead or in addition to VERSION_ID when the original system image version is important.

### Presentation information and links
HOME_URL=, DOCUMENTATION_URL=, SUPPORT_URL=, BUG_REPORT_URL=, PRIVACY_POLICY_URL=

Links to resources on the Internet related to the operating system. HOME_URL= should refer to the homepage of the operating system, or alternatively some homepage of the specific version of the operating system. DOCUMENTATION_URL= should refer to the main documentation page for this operating system. SUPPORT_URL= should refer to the main support page for the operating system, if there is any. This is primarily intended for operating systems which vendors provide support for. BUG_REPORT_URL= should refer to the main bug reporting page for the operating system, if there is any. This is primarily intended for operating systems that rely on community QA. PRIVACY_POLICY_URL= should refer to the main privacy policy page for the operating system, if there is any. These settings are optional, and providing only some of these settings is common. These URLs are intended to be exposed in "About this system" UIs behind links with captions such as "About this Operating System", "Obtain Support", "Report a Bug", or "Privacy Policy". The values should be in RFC3986 format[4], and should be "http:" or "https:" URLs, and possibly "mailto:" or "tel:". Only one URL shall be listed in each setting. If multiple resources need to be referenced, it is recommended to provide an online landing page linking all available resources. Examples: "HOME_URL="https://fedoraproject.org/"", "BUG_REPORT_URL="https://bugzilla.redhat.com/"".

LOGO=

A string, specifying the name of an icon as defined by freedesktop.org Icon Theme Specification[5]. This can be used by graphical applications to display an operating system's or distributor's logo. This field is optional and may not necessarily be implemented on all systems. Examples: "LOGO=fedora-logo", "LOGO=distributor-logo-opensuse"

ANSI_COLOR=

A suggested presentation color when showing the OS name on the console. This should be specified as string suitable for inclusion in the ESC [ m ANSI/ECMA-48 escape code for setting graphical rendition. This field is optional. Examples: "ANSI_COLOR="0;31"" for red, "ANSI_COLOR="1;34"" for light blue, or "ANSI_COLOR="0;38;2;60;110;180"" for Fedora blue.

### Distribution-level defaults and metadata
DEFAULT_HOSTNAME=

A string specifying the hostname if hostname(5) is not present and no other configuration source specifies the hostname. Must be either a single DNS label (a string composed of 7-bit ASCII lower-case characters and no spaces or dots, limited to the format allowed for DNS domain name labels), or a sequence of such labels separated by single dots that forms a valid DNS FQDN. The hostname must be at most 64 characters, which is a Linux limitation (DNS allows longer names). See org.freedesktop.hostname1(5) for a description of how systemd-hostnamed.service(8) determines the fallback hostname.

SYSEXT_LEVEL=

A lower-case string (mostly numeric, no spaces or other characters outside of 0–9, a–z, ".", "_" and "-") identifying the operating system extensions support level, to indicate which extension images are supported. See systemd-sysext(8)) for more information. Examples: "SYSEXT_LEVEL=2", "SYSEXT_LEVEL=15.14".

### Notes
If you are using this file to determine the OS or a specific version of it, use the ID and VERSION_ID fields, possibly with ID_LIKE as fallback for ID. When looking for an OS identification string for presentation to the user use the PRETTY_NAME field.

Note that operating system vendors may choose not to provide version information, for example to accommodate for rolling releases. In this case, VERSION and VERSION_ID may be unset. Applications should not rely on these fields to be set.

Operating system vendors may extend the file format and introduce new fields. It is highly recommended to prefix new fields with an OS specific name in order to avoid name clashes. Applications reading this file must ignore unknown fields.

Example: "DEBIAN_BTS="debbugs://bugs.debian.org/"".

Container and sandbox runtime managers may make the host's identification data available to applications by providing the host's /etc/os-release (if available, otherwise /usr/lib/os-release as a fallback) as /run/host/os-release.

## EXAMPLES
Example 1. os-release file for Fedora Workstation

```
NAME=Fedora
VERSION="32 (Workstation Edition)"
ID=fedora
VERSION_ID=32
PRETTY_NAME="Fedora 32 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:32"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f32/system-administrators-guide/"
SUPPORT_URL="https://fedoraproject.org/wiki/Communicating_and_getting_help"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=32
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=32
PRIVACY_POLICY_URL="https://fedoraproject.org/wiki/Legal:PrivacyPolicy"
VARIANT="Workstation Edition"
VARIANT_ID=workstation
```

Example 2. Reading os-release in sh(1)

```
#!/bin/sh -eu
test -e /etc/os-release && os_release='/etc/os-release' || os_release='/usr/lib/os-release'
. "${os_release}"
echo "Running on ${PRETTY_NAME:-Linux}"
if [ "${ID:-linux}" = "debian" ] || [ "${ID_LIKE#*debian*}" != "${ID_LIKE}" ]; then

    echo "Looks like Debian!"
fi
```

Example 3. Reading os-release in python(1) (versions >= 3.10)

```
#!/usr/bin/python
# SPDX-License-Identifier: CC0-1.0
import platform
os_release = platform.freedesktop_os_release()
pretty_name = os_release.get('PRETTY_NAME', 'Linux')
print(f'Running on {pretty_name!r}')
if 'fedora' in [os_release.get('ID', 'linux'),

                *os_release.get('ID_LIKE', '').split()]:

    print('Looks like Fedora!')
```

See docs for platform.freedesktop_os_release[6] for more details.

Example 4. Reading os-release in python(1) (any version)

```
#!/usr/bin/python
import ast
import re
import sys
def read_os_release():

    try:

        filename = '/etc/os-release'

        f = open(filename)

    except FileNotFoundError:

        filename = '/usr/lib/os-release'

        f = open(filename)

    for line_number, line in enumerate(f):

        line = line.rstrip()

        if not line or line.startswith('#'):

            continue

        if m := re.match(r'([A-Z][A-Z_0-9]+)=(.*)', line):

            name, val = m.groups()

            if val and val[0] in '"\'':

                val = ast.literal_eval(val)

            yield name, val

        else:

            print(f'{filename}:{line_number + 1}: bad line {line!r}',

                  file=sys.stderr)
os_release = dict(read_os_release())
pretty_name = os_release.get('PRETTY_NAME', 'Linux')
print(f'Running on {pretty_name!r}')
if 'debian' in [os_release.get('ID', 'linux'),

                *os_release.get('ID_LIKE', '').split()]:

    print('Looks like Debian!')
```

Note that the above version that uses the built-in implementation is preferred in most cases, and the open-coded version here is provided for reference.

## SEE ALSO
systemd(1), lsb_release(1), hostname(5), machine-id(5), machine-info(5)

## NOTES
1.

Announcement of /etc/os-release

http://0pointer.de/blog/projects/os-release

2.

initrd

https://www.kernel.org/doc/html/latest/admin-guide/initrd.html

3.

Common Platform Enumeration Specification

http://scap.nist.gov/specifications/cpe/

4.

RFC3986 format

https://tools.ietf.org/html/rfc3986

5.

freedesktop.org Icon Theme Specification

http://standards.freedesktop.org/icon-theme-spec/latest

6.

platform.freedesktop_os_release

https://docs.python.org/3/library/platform.html#platform.freedesktop_os_release


pstore.conf

title: pstore.conf(5)

summary: PStore configuration file

text:
# pstore.conf(5)

## NAME
pstore.conf, pstore.conf.d - PStore configuration file

## SYNOPSIS
/etc/systemd/pstore.conf /etc/systemd/pstore.conf.d/*

## DESCRIPTION
This file configures the behavior of systemd-pstore(8), a tool for archiving the contents of the persistent storage filesystem, pstore[1].

## CONFIGURATION DIRECTORIES AND PRECEDENCE
The default configuration is set during compilation, so configuration is only needed when it is necessary to deviate from those defaults. Initially, the main configuration file in /etc/systemd/ contains commented out entries showing the defaults as a guide to the administrator. Local overrides can be created by editing this file or by creating drop-ins, as described below. Using drop-ins for local configuration is recommended over modifications to the main configuration file.

In addition to the "main" configuration file, drop-in configuration snippets are read from /lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/, and /etc/systemd/*.conf.d/. Those drop-ins have higher precedence and override the main configuration file. Files in the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order, regardless of in which of the subdirectories they reside. When multiple files specify the same option, for options which accept just a single value, the entry in the file sorted last takes precedence, and for options which accept a list of values, entries are collected as they occur in the sorted files.

When packages need to customize the configuration, they can install drop-ins under /usr/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. Drop-ins have to be used to override package drop-ins, since the main configuration file has lower precedence. It is recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering of the files.

To disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file.

## OPTIONS
All options are configured in the [PStore] section:

Storage=

Controls where to archive (i.e. copy) files from the pstore filesystem. One of "none", "external", and "journal". When "none", the tool exits without processing files in the pstore filesystem. When "external" (the default), files are archived into /var/lib/systemd/pstore/, and logged into the journal. When "journal", pstore file contents are logged only in the journal.

Unlink=

Controls whether or not files are removed from pstore after processing. Takes a boolean value. When true, a pstore file is removed from the pstore once it has been archived (either to disk or into the journal). When false, processing of pstore files occurs normally, but the files remain in the pstore. The default is true in order to maintain the pstore in a nearly empty state, so that the pstore has storage available for the next kernel error event.

The defaults for all values are listed as comments in the template /etc/systemd/pstore.conf file that is installed by default.

## SEE ALSO
systemd-journald.service(8)

## NOTES
1.

pstore

https://www.kernel.org/doc/Documentation/ABI/testing/pstore


repart.d

title: repart.d(5)

summary: Partition Definition Files for Automatic Boot\-Time Repartitioning

text:
# repart.d(5)

## NAME
repart.d - Partition Definition Files for Automatic Boot-Time Repartitioning

## SYNOPSIS

```
/etc/repart.d/*.conf
/run/repart.d/*.conf
/usr/lib/repart.d/*.conf

```

## DESCRIPTION
repart.d/*.conf files describe basic properties of partitions of block devices of the local system. They may be used to declare types, names and sizes of partitions that shall exist. The systemd-repart(8) service reads these files and attempts to add new partitions currently missing and enlarge existing partitions according to these definitions. Operation is generally incremental, i.e. when applied, what exists already is left intact, and partitions are never shrunk, moved or deleted.

These definition files are useful for implementing operating system images that are prepared and delivered with minimally sized images (for example lacking any state or swap partitions), and which on first boot automatically take possession of any remaining disk space following a few basic rules.

Currently, support for partition definition files is only implemented for GPT partitition tables.

Partition files are generally matched against any partitions already existing on disk in a simple algorithm: the partition files are sorted by their filename (ignoring the directory prefix), and then compared in order against existing partitions matching the same partition type UUID. Specifically, the first existing partition with a specific partition type UUID is assigned the first definition file with the same partition type UUID, and the second existing partition with a specific type UUID the second partition file with the same type UUID, and so on. Any left-over partition files that have no matching existing partition are assumed to define new partition that shall be created. Such partitions are appended to the end of the partition table, in the order defined by their names utilizing the first partition slot greater than the highest slot number currently in use. Any existing partitions that have no matching partition file are left as they are.

Note that these definitions may only be used to create and initialize new partitions or to grow existing ones. In the latter case it will not grow the contained files systems however; separate mechanisms, such as systemd-growfs(8) may be used to grow the file systems inside of these partitions. Partitions may also be marked for automatic growing via the GrowFileSystem= setting, in which case the file system is grown on first mount by tools that respect this flag. See below for details.

## [PARTITION] SECTION OPTIONS
Type=

The GPT partition type UUID to match. This may be a GPT partition type UUID such as 4f68bce3-e8cd-4db1-96e7-fbcaf984b709, or one of the following special identifiers: Table 1. GPT partition type identifiers

Identifier

Explanation

esp

EFI System Partition

xbootldr

Extended Boot Loader Partition

swap

Swap partition

home

Home (/home/) partition

srv

Server data (/srv/) partition

var

Variable data (/var/) partition

tmp

Temporary data (/var/tmp/) partition

linux-generic

Generic Linux file system partition

root

Root file system partition type appropriate for the local architecture (an alias for an architecture root file system partition type listed below, e.g. root-x86-64)

root-verity

Verity data for the root file system partition for the local architecture

root-secondary

Root file system partition of the secondary architecture of the local architecture (usually the matching 32bit architecture for the local 64bit architecture)

root-secondary-verity

Verity data for the root file system partition of the secondary architecture

root-x86

Root file system partition for the x86 (32bit, aka i386) architecture

root-x86-verity

Verity data for the x86 (32bit) root file system partition

root-x86-64

Root file system partition for the x86_64 (64bit, aka amd64) architecture

root-x86-64-verity

Verity data for the x86_64 (64bit) root file system partition

root-arm

Root file system partition for the ARM (32bit) architecture

root-arm-verity

Verity data for the ARM (32bit) root file system partition

root-arm64

Root file system partition for the ARM (64bit, aka aarch64) architecture

root-arm64-verity

Verity data for the ARM (64bit, aka aarch64) root file system partition

root-ia64

Root file system partition for the ia64 architecture

root-ia64-verity

Verity data for the ia64 root file system partition

root-riscv32

Root file system partition for the RISC-V 32-bit architecture

root-riscv32-verity

Verity data for the RISC-V 32-bit root file system partition

root-riscv64

Root file system partition for the RISC-V 64-bit architecture

root-riscv64-verity

Verity data for the RISC-V 64-bit root file system partition

usr

/usr/ file system partition type appropriate for the local architecture (an alias for an architecture /usr/ file system partition type listed below, e.g. usr-x86-64)

usr-verity

Verity data for the /usr/ file system partition for the local architecture

usr-secondary

/usr/ file system partition of the secondary architecture of the local architecture (usually the matching 32bit architecture for the local 64bit architecture)

usr-secondary-verity

Verity data for the /usr/ file system partition of the secondary architecture

usr-x86

/usr/ file system partition for the x86 (32bit, aka i386) architecture

usr-x86-verity

Verity data for the x86 (32bit) /usr/ file system partition

usr-x86-64

/usr/ file system partition for the x86_64 (64bit, aka amd64) architecture

usr-x86-64-verity

Verity data for the x86_64 (64bit) /usr/ file system partition

usr-arm

/usr/ file system partition for the ARM (32bit) architecture

usr-arm-verity

Verity data for the ARM (32bit) /usr/ file system partition

usr-arm64

/usr/ file system partition for the ARM (64bit, aka aarch64) architecture

usr-arm64-verity

Verity data for the ARM (64bit, aka aarch64) /usr/ file system partition

usr-ia64

/usr/ file system partition for the ia64 architecture

usr-ia64-verity

Verity data for the ia64 /usr/ file system partition

usr-riscv32

/usr/ file system partition for the RISC-V 32-bit architecture

usr-riscv32-verity

Verity data for the RISC-V 32-bit /usr/ file system partition

usr-riscv64

/usr/ file system partition for the RISC-V 64-bit architecture

usr-riscv64-verity

Verity data for the RISC-V 64-bit /usr/ file system partition

This setting defaults to

linux-generic.

Most of the partition type UUIDs listed above are defined in the Discoverable Partitions Specification[1].

Label=

The textual label to assign to the partition if none is assigned yet. Note that this setting is not used for matching. It is also not used when a label is already set for an existing partition. It is thus only used when a partition is newly created or when an existing one had a no label set (that is: an empty label). If not specified a label derived from the partition type is automatically used. Simple specifier expansion is supported, see below.

UUID=

The UUID to assign to the partition if none is assigned yet. Note that this setting is not used for matching. It is also not used when a UUID is already set for an existing partition. It is thus only used when a partition is newly created or when an existing one had a all-zero UUID set. If not specified a UUID derived from the partition type is automatically used.

Priority=

A numeric priority to assign to this partition, in the range -2147483648...2147483647, with smaller values indicating higher priority, and higher values indicating smaller priority. This priority is used in case the configured size constraints on the defined partitions do not permit fitting all partitions onto the available disk space. If the partitions do not fit, the highest numeric partition priority of all defined partitions is determined, and all defined partitions with this priority are removed from the list of new partitions to create (which may be multiple, if the same priority is used for multiple partitions). The fitting algorithm is then tried again. If the partitions still do not fit, the now highest numeric partition priority is determined, and the matching partitions removed too, and so on. Partitions of a priority of 0 or lower are never removed. If all partitions with a priority above 0 are removed and the partitions still do not fit on the device the operation fails. Note that this priority has no effect on ordering partitions, for that use the alphabetical order of the filenames of the partition definition files. Defaults to 0.

Weight=

A numeric weight to assign to this partition in the range 0...1000000. Available disk space is assigned the defined partitions according to their relative weights (subject to the size constraints configured with SizeMinBytes=, SizeMaxBytes=), so that a partition with weight 2000 gets double the space as one with weight 1000, and a partition with weight 333 a third of that. Defaults to 1000. The Weight= setting is used to distribute available disk space in an "elastic" fashion, based on the disk size and existing partitions. If a partition shall have a fixed size use both SizeMinBytes= and SizeMaxBytes= with the same value in order to fixate the size to one value, in which case the weight has no effect.

PaddingWeight=

Similar to Weight= but sets a weight for the free space after the partition (the "padding"). When distributing available space the weights of all partitions and all defined padding is summed, and then each partition and padding gets the fraction defined by its weight. Defaults to 0, i.e. by default no padding is applied. Padding is useful if empty space shall be left for later additions or a safety margin at the end of the device or between partitions.

SizeMinBytes=, SizeMaxBytes=

Specifies minimum and maximum size constraints in bytes. Takes the usual K, M, G, T, ... suffixes (to the base of 1024). If SizeMinBytes= is specified the partition is created at or grown to at least the specified size. If SizeMaxBytes= is specified the partition is created at or grown to at most the specified size. The precise size is determined through the weight value value configured with Weight=, see above. When SizeMinBytes= is set equal to SizeMaxBytes= the configured weight has no effect as the partition is explicitly sized to the specified fixed value. Note that partitions are never created smaller than 4096 bytes, and since partitions are never shrunk the previous size of the partition (in case the partition already exists) is also enforced as lower bound for the new size. The values should be specified as multiples of 4096 bytes, and are rounded upwards (in case of SizeMinBytes=) or downwards (in case of SizeMaxBytes=) otherwise. If the backing device does not provide enough space to fulfill the constraints placing the partition will fail. For partitions that shall be created, depending on the setting of Priority= (see above) the partition might be dropped and the placing algorithm restarted. By default a minimum size constraint of 10M and no maximum size constraint is set.

PaddingMinBytes=, PaddingMaxBytes=

Specifies minimum and maximum size constraints in bytes for the free space after the partition (the "padding"). Semantics are similar to SizeMinBytes= and SizeMaxBytes=, except that unlike partition sizes free space can be shrunk and can be as small as zero. By default no size constraints on padding are set, so that only PaddingWeight= determines the size of the padding applied.

CopyBlocks=

Takes a path to a regular file, block device node or directory, or the special value "auto". If specified and the partition is newly created, the data from the specified path is written to the newly created partition, on the block level. If a directory is specified, the backing block device of the file system the directory is on is determined, and the data read directly from that. This option is useful to efficiently replicate existing file systems onto new partitions on the block level — for example to build a simple OS installer or an OS image builder. If the special value "auto" is specified, the source to copy from is automatically picked up from the running system (or the image specified with --image= — if used). A partition that matches both the configured partition type (as declared with Type= described above), and the currently mounted directory appropriate for that partition type is determined. For example, if the partition type is set to "root" the partition backing the root directory (/) is used as source to copy from — if its partition type is set to "root" as well. If the declared type is "usr" the partition backing /usr/ is used as source to copy blocks from — if its partition type is set to "usr" too. The logic is capable of automatically tracking down the backing partitions for encrypted and Verity-enabled volumes. "CopyBlocks=auto" is useful for implementing "self-replicating" systems, i.e. systems that are their own installer.

The file specified here must have a size that is a multiple of the basic block size 512 and not be empty. If this option is used, the size allocation algorithm is slightly altered: the partition is created as least as big as required to fit the data in, i.e. the data size is an additional minimum size value taken into consideration for the allocation algorithm, similar to and in addition to the SizeMin= value configured above.

This option has no effect if the partition it is declared for already exists, i.e. existing data is never overwritten. Note that the data is copied in before the partition table is updated, i.e. before the partition actually is persistently created. This provides robustness: it is guaranteed that the partition either doesn't exist or exists fully populated; it is not possible that the partition exists but is not or only partially populated.

This option cannot be combined with Format= or CopyFiles=.

Format=

Takes a file system name, such as "ext4", "btrfs", "xfs" or "vfat", or the special value "swap". If specified and the partition is newly created it is formatted with the specified file system (or as swap device). The file system UUID and label are automatically derived from the partition UUID and label. If this option is used, the size allocation algorithm is slightly altered: the partition is created as least as big as required for the minimal file system of the specified type (or 4KiB if the minimal size is not known). This option has no effect if the partition already exists.

Similar to the behaviour of CopyBlocks= the file system is formatted before the partition is created, ensuring that the partition only ever exists with a fully initialized file system.

This option cannot be combined with CopyBlocks=.

CopyFiles=

Takes a pair of colon separated absolute file system paths. The first path refers to a source file or directory on the host, the second path refers to a target in the file system of the newly created partition and formatted file system. This setting may be used to copy files or directories from the host into the file system that is created due to the Format= option. If CopyFiles= is used without Format= specified explicitly, "Format=" with a suitable default is implied (currently "ext4", but this may change in the future). This option may be used multiple times to copy multiple files or directories from host into the newly formatted file system. The colon and second path may be omitted in which case the source path is also used as the target path (relative to the root of the newly created file system). If the source path refers to a directory it is copied recursively. This option has no effect if the partition already exists: it cannot be used to copy additional files into an existing partition, it may only be used to populate a file system created anew.

The copy operation is executed before the file system is registered in the partition table, thus ensuring that a file system populated this way only ever exists fully initialized.

This option cannot be combined with CopyBlocks=.

When systemd-repart is invoked with the --image= or --root= command line switches the source paths specified are taken relative to the specified root directory or disk image root.

MakeDirectories=

Takes one or more absolute paths, separated by whitespace, each declaring a directory to create within the new file system. Behaviour is similar to CopyFiles=, but instead of copying in a set of files this just creates the specified directories with the default mode of 0755 owned by the root user and group, plus all their parent directories (with the same ownership and access mode). To configure directories with different ownership or access mode, use CopyFiles= and specify a source tree to copy containing appropriately owned/configured directories. This option may be used more than once to create multiple directories. When CopyFiles= and MakeDirectories= are used together the former is applied first. If a directory listed already exists no operation is executed (in particular, the ownership/access mode of the directories is left as is). The primary usecase for this option is to create a minimal set of directories that may be mounted over by other partitions contained in the same disk image. For example, a disk image where the root file system is formatted at first boot might want to automatically pre-create /usr/ in it this way, so that the "usr" partition may over-mount it.

Consider using systemd-tmpfiles(8) with its --image= option to pre-create other, more complex directory hierarchies (as well as other inodes) with fine-grained control of ownership, access modes and other file attributes.

Encrypt=

Takes one of "off", "key-file", "tpm2" and "key-file+tpm2" (alternatively, also accepts a boolean value, which is mapped to "off" when false, and "key-file" when true). Defaults to "off". If not "off" the partition will be formatted with a LUKS2 superblock, before the blocks configured with CopyBlocks= are copied in or the file system configured with Format= is created. The LUKS2 UUID is automatically derived from the partition UUID in a stable fashion. If "key-file" or "key-file+tpm2" is used, a key is added to the LUKS2 superblock, configurable with the --key-file= option to systemd-repart. If "tpm2" or "key-file+tpm2" is used, a key is added to the LUKS2 superblock that is enrolled to the local TPM2 chip, as configured with the --tpm2-device= and --tpm2-pcrs= options to systemd-repart.

When used this slightly alters the size allocation logic as the implicit, minimal size limits of Format= and CopyBlocks= are increased by the space necessary for the LUKS2 superblock (see above).

This option has no effect if the partition already exists.

FactoryReset=

Takes a boolean argument. If specified the partition is marked for removal during a factory reset operation. This functionality is useful to implement schemes where images can be reset into their original state by removing partitions and creating them anew. Defaults to off.

Flags=

Configures the 64bit GPT partition flags field to set for the partition when creating it. This option has no effect if the partition already exists. If not specified the flags values is set to all zeroes, except for the three bits that can also be configured via NoAuto=, ReadOnly= and GrowFileSystem=; see below for details on the defaults for these three flags. Specify the flags value in hexadecimal (by prefixing it with "0x"), binary (prefix "0b") or decimal (no prefix).

NoAuto=, ReadOnly=, GrowFileSystem=

Configures the No-Auto, Read-Only and Grow-File-System partition flags (bit 63, 60 and 59) of the partition table entry, as defined by the Discoverable Partitions Specification[1]. Only available for partition types supported by the specification. This option is a friendly way to set bits 63, 60 and 59 of the partition flags value without setting any of the other bits, and may be set via Flags= too, see above. If Flags= is used in conjunction with one or more of NoAuto=/ReadOnly=/GrowFileSystem= the latter control the value of the relevant flags, i.e. the high-level settings NoAuto=/ReadOnly=/GrowFileSystem= override the relevant bits of the low-level setting Flags=.

Note that the three flags affect only automatic partition mounting, as implemented by systemd-gpt-auto-generator(8) or the --image= option of various commands (such as systemd-nspawn(1)). It has no effect on explicit mounts, such as those done via mount(8) or fstab(5).

If both bit 50 and 59 are set for a partition (i.e. the partition is marked both read-only and marked for file system growing) the latter is typically without effect: the read-only flag takes precedence in most tools reading these flags, and since growing the file system involves writing to the partition it is consequently ignored.

NoAuto= defaults to off. ReadOnly= defaults to on for Verity partition types, and off for all others. GrowFileSystem= defaults to on for all partition types that support it, except if the partition is marked read-only (and thus effectively, defaults to off for Verity partitions).

## SPECIFIERS
Specifiers may be used in the Label=, CopyBlocks=, CopyFiles=, MakeDirectories= settings. The following expansions are understood:

Table 2. Specifiers available

Specifier

Meaning

Details

"%a"

Architecture

A short string identifying the architecture of the local system. A string such as x86, x86-64 or arm64. See the architectures defined for ConditionArchitecture= in systemd.unit(5) for a full list.

"%A"

Operating system image version

The operating system image version identifier of the running system, as read from the IMAGE_VERSION= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%b"

Boot ID

The boot ID of the running system, formatted as string. See random(4) for more information.

"%B"

Operating system build ID

The operating system build identifier of the running system, as read from the BUILD_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%H"

Host name

The hostname of the running system.

"%l"

Short host name

The hostname of the running system, truncated at the first dot to remove any domain component.

"%m"

Machine ID

The machine ID of the running system, formatted as string. See machine-id(5) for more information.

"%M"

Operating system image identifier

The operating system image identifier of the running system, as read from the IMAGE_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%o"

Operating system ID

The operating system identifier of the running system, as read from the ID= field of /etc/os-release. See os-release(5) for more information.

"%v"

Kernel release

Identical to uname -r output.

"%w"

Operating system version ID

The operating system version identifier of the running system, as read from the VERSION_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%W"

Operating system variant ID

The operating system variant identifier of the running system, as read from the VARIANT_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%T"

Directory for temporary files

This is either /tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)

"%V"

Directory for larger and persistent temporary files

This is either /var/tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)

"%%"

Single percent sign

Use "%%" in place of "%" to specify a single percent sign.

## EXAMPLES
Example 1. Grow the root partition to the full disk size at first boot

With the following file the root partition is automatically grown to the full disk if possible during boot.

```
# /usr/lib/repart.d/50-root.conf
[Partition]
Type=root
```

Example 2. Create a swap and home partition automatically on boot, if missing

The home partition gets all available disk space while the swap partition gets 1G at most and 64M at least. We set a priority > 0 on the swap partition to ensure the swap partition is not used if not enough space is available. For every three bytes assigned to the home partition the swap partition gets assigned one.

```
# /usr/lib/repart.d/60-home.conf
[Partition]
Type=home
```

```
# /usr/lib/repart.d/70-swap.conf
[Partition]
Type=swap
SizeMinBytes=64M
SizeMaxBytes=1G
Priority=1
Weight=333
```

Example 3. Create B partitions in an A/B Verity setup, if missing

Let's say the vendor intends to update OS images in an A/B setup, i.e. with two root partitions (and two matching Verity partitions) that shall be used alternatingly during upgrades. To minimize image sizes the original image is shipped only with one root and one Verity partition (the "A" set), and the second root and Verity partitions (the "B" set) shall be created on first boot on the free space on the medium.

```
# /usr/lib/repart.d/50-root.conf
[Partition]
Type=root
SizeMinBytes=512M
SizeMaxBytes=512M
```

```
# /usr/lib/repart.d/60-root-verity.conf
[Partition]
Type=root-verity
SizeMinBytes=64M
SizeMaxBytes=64M
```

The definitions above cover the "A" set of root partition (of a fixed 512M size) and Verity partition for the root partition (of a fixed 64M size). Let's use symlinks to create the "B" set of partitions, since after all they shall have the same properties and sizes as the "A" set.

```
# ln -s 50-root.conf /usr/lib/repart.d/70-root-b.conf
# ln -s 60-root-verity.conf /usr/lib/repart.d/80-root-verity-b.conf
```

## SEE ALSO
systemd(1), systemd-repart(8), sfdisk(8), systemd-cryptenroll(1)

## NOTES
1.

Discoverable Partitions Specification

https://systemd.io/DISCOVERABLE_PARTITIONS


sysctl.d

title: sysctl.d(5)

summary: Configure kernel parameters at boot

text:
# sysctl.d(5)

## NAME
sysctl.d - Configure kernel parameters at boot

## SYNOPSIS
/etc/sysctl.d/*.conf

/run/sysctl.d/*.conf

/lib/sysctl.d/*.conf

```
key.name.under.proc.sys = some value
key/name/under/proc/sys = some value
key/middle.part.with.dots/foo = 123
key.middle/part/with/dots.foo = 123
-key.that.will.not.fail = value
key.pattern.*.with.glob = whatever
-key.pattern.excluded.with.glob
key.pattern.overridden.with.glob = custom
```

## DESCRIPTION
At boot, systemd-sysctl.service(8) reads configuration files from the above directories to configure sysctl(8) kernel parameters.

## CONFIGURATION FORMAT
The configuration files contain a list of variable assignments, separated by newlines. Empty lines and lines whose first non-whitespace character is "#" or ";" are ignored.

Note that either "/" or "." may be used as separators within sysctl variable names. If the first separator is a slash, remaining slashes and dots are left intact. If the first separator is a dot, dots and slashes are interchanged. "kernel.domainname=foo" and "kernel/domainname=foo" are equivalent and will cause "foo" to be written to /proc/sys/kernel/domainname. Either "net.ipv4.conf.enp3s0/200.forwarding" or "net/ipv4/conf/enp3s0.200/forwarding" may be used to refer to /proc/sys/net/ipv4/conf/enp3s0.200/forwarding. A glob glob(7) pattern may be used to write the same value to all matching keys. Keys for which an explicit pattern exists will be excluded from any glob matching. In addition, a key may be explicitly excluded from being set by any matching glob patterns by specifying the key name prefixed with a "-" character and not followed by "=", see SYNOPSIS.

Any access permission errors and attempts to write variables not present on the local system are logged at debug level and do not cause the service to fail. Other types of errors when setting variables are logged with higher priority and cause the service to return failure at the end (after processing other variables). As an exception, if a variable assignment is prefixed with a single "-" character, failure to set the variable for any reason will be logged at debug level and will not cause the service to fail.

The settings configured with sysctl.d files will be applied early on boot. The network interface-specific options will also be applied individually for each network interface as it shows up in the system. (More specifically, net.ipv4.conf.*, net.ipv6.conf.*, net.ipv4.neigh.* and net.ipv6.neigh.*).

Many sysctl parameters only become available when certain kernel modules are loaded. Modules are usually loaded on demand, e.g. when certain hardware is plugged in or network brought up. This means that systemd-sysctl.service(8) which runs during early boot will not configure such parameters if they become available after it has run. To set such parameters, it is recommended to add an udev(7) rule to set those parameters when they become available. Alternatively, a slightly simpler and less efficient option is to add the module to modules-load.d(5), causing it to be loaded statically before sysctl settings are applied (see example below).

## CONFIGURATION DIRECTORIES AND PRECEDENCE
Configuration files are read from directories in /etc/, /run/, /usr/local/lib/, and /lib/, in order of precedence, as listed in the SYNOPSIS section above. Files must have the ".conf" extension. Files in /etc/ override files with the same name in /run/, /usr/local/lib/, and /lib/. Files in /run/ override files with the same name under /usr/.

All configuration files are sorted by their filename in lexicographic order, regardless of which of the directories they reside in. If multiple files specify the same option, the entry in the file with the lexicographically latest name will take precedence. Thus, the configuration in a certain file may either be replaced completely (by placing a file with the same name in a directory with higher priority), or individual settings might be changed (by specifying additional settings in a file with a different name that is ordered later).

Packages should install their configuration files in /usr/lib/ (distribution packages) or /usr/local/lib/ (local installs). Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. It is recommended to prefix all filenames with a two-digit number and a dash, to simplify the ordering of the files.

If the administrator wants to disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file. If the vendor configuration file is included in the initrd image, the image has to be regenerated.

## EXAMPLES
Example 1. Set kernel YP domain name

/etc/sysctl.d/domain-name.conf:

```
kernel.domainname=example.com
```

Example 2. Apply settings available only when a certain module is loaded (method one)

/etc/udev/rules.d/99-bridge.rules:

```
ACTION=="add", SUBSYSTEM=="module", KERNEL=="br_netfilter", \

      RUN+="/lib/systemd/systemd-sysctl --prefix=/net/bridge"
```

/etc/sysctl.d/bridge.conf:

```
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
```

This method applies settings when the module is loaded. Please note that, unless the br_netfilter module is loaded, bridged packets will not be filtered by Netfilter (starting with kernel 3.18), so simply not loading the module is sufficient to avoid filtering.

Example 3. Apply settings available only when a certain module is loaded (method two)

/etc/modules-load.d/bridge.conf:

```
br_netfilter
```

/etc/sysctl.d/bridge.conf:

```
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
```

This method forces the module to be always loaded. Please note that, unless the br_netfilter module is loaded, bridged packets will not be filtered with Netfilter (starting with kernel 3.18), so simply not loading the module is sufficient to avoid filtering.

Example 4. Set network routing properties for all interfaces

/etc/sysctl.d/20-rp_filter.conf:

```
net.ipv4.conf.default.rp_filter = 2
net.ipv4.conf.*.rp_filter = 2
-net.ipv4.conf.all.rp_filter
net.ipv4.conf.hub0.rp_filter = 1
```

The rp_filter key will be set to "2" for all interfaces, except "hub0". We set net.ipv4.conf.default.rp_filter first, so any interfaces which are added later will get this value (this also covers any interfaces detected while we're running). The glob matches any interfaces which were detected earlier. The glob will also match net.ipv4.conf.all.rp_filter, which we don't want to set at all, so it is explicitly excluded. And "hub0" is excluded from the glob because it has an explicit setting.

## SEE ALSO
systemd(1), systemd-sysctl.service(8), systemd-delta(1), sysctl(8), sysctl.conf(5), modprobe(8)


systemd-sleep.conf

title: systemd-sleep.conf(5)

text:
# systemd-sleep.conf(5)

## NAME
systemd-sleep.conf, sleep.conf.d - Suspend and hibernation configuration file

## SYNOPSIS
/etc/systemd/sleep.conf

/etc/systemd/sleep.conf.d/*.conf

/run/systemd/sleep.conf.d/*.conf

/lib/systemd/sleep.conf.d/*.conf

## DESCRIPTION
systemd supports four general power-saving modes:

suspend

a low-power state where execution of the OS is paused, and complete power loss might result in lost data, and which is fast to enter and exit. This corresponds to suspend, standby, or freeze states as understood by the kernel.

hibernate

a low-power state where execution of the OS is paused, and complete power loss does not result in lost data, and which might be slow to enter and exit. This corresponds to the hibernation as understood by the kernel.

hybrid-sleep

a low-power state where execution of the OS is paused, which might be slow to enter, and on complete power loss does not result in lost data but might be slower to exit in that case. This mode is called suspend-to-both by the kernel.

suspend-then-hibernate

A low power state where the system is initially suspended (the state is stored in RAM). If not interrupted within the delay specified by HibernateDelaySec=, the system will be woken using an RTC alarm and hibernated (the state is then stored on disk).

Settings in these files determine what strings will be written to /sys/power/disk and /sys/power/state by systemd-sleep(8) when systemd(1) attempts to suspend or hibernate the machine. See systemd.syntax(7) for a general description of the syntax.

## CONFIGURATION DIRECTORIES AND PRECEDENCE
The default configuration is set during compilation, so configuration is only needed when it is necessary to deviate from those defaults. Initially, the main configuration file in /etc/systemd/ contains commented out entries showing the defaults as a guide to the administrator. Local overrides can be created by editing this file or by creating drop-ins, as described below. Using drop-ins for local configuration is recommended over modifications to the main configuration file.

In addition to the "main" configuration file, drop-in configuration snippets are read from /lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/, and /etc/systemd/*.conf.d/. Those drop-ins have higher precedence and override the main configuration file. Files in the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order, regardless of in which of the subdirectories they reside. When multiple files specify the same option, for options which accept just a single value, the entry in the file sorted last takes precedence, and for options which accept a list of values, entries are collected as they occur in the sorted files.

When packages need to customize the configuration, they can install drop-ins under /usr/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. Drop-ins have to be used to override package drop-ins, since the main configuration file has lower precedence. It is recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering of the files.

To disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file.

## OPTIONS
The following options can be configured in the [Sleep] section of /etc/systemd/sleep.conf or a sleep.conf.d file:

AllowSuspend=, AllowHibernation=, AllowSuspendThenHibernate=, AllowHybridSleep=

By default any power-saving mode is advertised if possible (i.e. the kernel supports that mode, the necessary resources are available). Those switches can be used to disable specific modes. If AllowHibernation=no or AllowSuspend=no is used, this implies AllowSuspendThenHibernate=no and AllowHybridSleep=no, since those methods use both suspend and hibernation internally. AllowSuspendThenHibernate=yes and AllowHybridSleep=yes can be used to override and enable those specific modes.

SuspendMode=, HibernateMode=, HybridSleepMode=

The string to be written to /sys/power/disk by, respectively, systemd-suspend.service(8), systemd-hibernate.service(8), or systemd-hybrid-sleep.service(8). More than one value can be specified by separating multiple values with whitespace. They will be tried in turn, until one is written without error. If neither succeeds, the operation will be aborted. systemd-suspend-then-hibernate.service(8) uses the value of SuspendMode= when suspending and the value of HibernateMode= when hibernating.

SuspendState=, HibernateState=, HybridSleepState=

The string to be written to /sys/power/state by, respectively, systemd-suspend.service(8), systemd-hibernate.service(8), or systemd-hybrid-sleep.service(8). More than one value can be specified by separating multiple values with whitespace. They will be tried in turn, until one is written without error. If neither succeeds, the operation will be aborted. systemd-suspend-then-hibernate.service(8) uses the value of SuspendState= when suspending and the value of HibernateState= when hibernating.

HibernateDelaySec=

The amount of time the system spends in suspend mode before the system is automatically put into hibernate mode, when using systemd-suspend-then-hibernate.service(8). Defaults to 2h.

## EXAMPLE: FREEZE
Example: to exploit the “freeze” mode added in Linux 3.9, one can use systemctl suspend with

```
[Sleep]
SuspendState=freeze
```

## SEE ALSO
systemd-sleep(8), systemd-suspend.service(8), systemd-hibernate.service(8), systemd-hybrid-sleep.service(8), systemd-suspend-then-hibernate.service(8), systemd(1), systemd.directives(7)


systemd-system.conf

title: systemd-system.conf(5)

text:
# systemd-system.conf(5)

## NAME
systemd-system.conf, system.conf.d, systemd-user.conf, user.conf.d - System and session service manager configuration files

## SYNOPSIS
/etc/systemd/system.conf, /etc/systemd/system.conf.d/*.conf, /run/systemd/system.conf.d/*.conf, /lib/systemd/system.conf.d/*.conf

~/.config/systemd/user.conf, /etc/systemd/user.conf, /etc/systemd/user.conf.d/*.conf, /run/systemd/user.conf.d/*.conf, /usr/lib/systemd/user.conf.d/*.conf

## DESCRIPTION
When run as a system instance, systemd interprets the configuration file system.conf and the files in system.conf.d directories; when run as a user instance, it interprets the configuration file user.conf (either in the home directory of the user, or if not found, under /etc/systemd/) and the files in user.conf.d directories. These configuration files contain a few settings controlling basic manager operations.

See systemd.syntax(7) for a general description of the syntax.

## CONFIGURATION DIRECTORIES AND PRECEDENCE
The default configuration is set during compilation, so configuration is only needed when it is necessary to deviate from those defaults. Initially, the main configuration file in /etc/systemd/ contains commented out entries showing the defaults as a guide to the administrator. Local overrides can be created by editing this file or by creating drop-ins, as described below. Using drop-ins for local configuration is recommended over modifications to the main configuration file.

In addition to the "main" configuration file, drop-in configuration snippets are read from /lib/systemd/*.conf.d/, /usr/local/lib/systemd/*.conf.d/, and /etc/systemd/*.conf.d/. Those drop-ins have higher precedence and override the main configuration file. Files in the *.conf.d/ configuration subdirectories are sorted by their filename in lexicographic order, regardless of in which of the subdirectories they reside. When multiple files specify the same option, for options which accept just a single value, the entry in the file sorted last takes precedence, and for options which accept a list of values, entries are collected as they occur in the sorted files.

When packages need to customize the configuration, they can install drop-ins under /usr/. Files in /etc/ are reserved for the local administrator, who may use this logic to override the configuration files installed by vendor packages. Drop-ins have to be used to override package drop-ins, since the main configuration file has lower precedence. It is recommended to prefix all filenames in those subdirectories with a two-digit number and a dash, to simplify the ordering of the files.

To disable a configuration file supplied by the vendor, the recommended way is to place a symlink to /dev/null in the configuration directory in /etc/, with the same filename as the vendor configuration file.

## OPTIONS
All options are configured in the [Manager] section:

LogColor=, LogLevel=, LogLocation=, LogTarget=, LogTime=, DumpCore=yes, CrashChangeVT=no, CrashShell=no, CrashReboot=no, ShowStatus=yes, DefaultStandardOutput=journal, DefaultStandardError=inherit

Configures various parameters of basic manager operation. These options may be overridden by the respective process and kernel command line arguments. See systemd(1) for details.

CtrlAltDelBurstAction=

Defines what action will be performed if user presses Ctrl-Alt-Delete more than 7 times in 2s. Can be set to "reboot-force", "poweroff-force", "reboot-immediate", "poweroff-immediate" or disabled with "none". Defaults to "reboot-force".

CPUAffinity=

Configures the CPU affinity for the service manager as well as the default CPU affinity for all forked off processes. Takes a list of CPU indices or ranges separated by either whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated by a dash. This option may be specified more than once, in which case the specified CPU affinity masks are merged. If the empty string is assigned, the mask is reset, all assignments prior to this will have no effect. Individual services may override the CPU affinity for their processes with the CPUAffinity= setting in unit files, see systemd.exec(5).

NUMAPolicy=

Configures the NUMA memory policy for the service manager and the default NUMA memory policy for all forked off processes. Individual services may override the default policy with the NUMAPolicy= setting in unit files, see systemd.exec(5).

NUMAMask=

Configures the NUMA node mask that will be associated with the selected NUMA policy. Note that default and local NUMA policies don't require explicit NUMA node mask and value of the option can be empty. Similarly to NUMAPolicy=, value can be overridden by individual services in unit files, see systemd.exec(5).

RuntimeWatchdogSec=, RebootWatchdogSec=, KExecWatchdogSec=

Configure the hardware watchdog at runtime and at reboot. Takes a timeout value in seconds (or in other time units if suffixed with "ms", "min", "h", "d", "w"). If RuntimeWatchdogSec= is set to a non-zero value, the watchdog hardware (/dev/watchdog or the path specified with WatchdogDevice= or the kernel option systemd.watchdog-device=) will be programmed to automatically reboot the system if it is not contacted within the specified timeout interval. The system manager will ensure to contact it at least once in half the specified timeout interval. This feature requires a hardware watchdog device to be present, as it is commonly the case in embedded and server systems. Not all hardware watchdogs allow configuration of all possible reboot timeout values, in which case the closest available timeout is picked. RebootWatchdogSec= may be used to configure the hardware watchdog when the system is asked to reboot. It works as a safety net to ensure that the reboot takes place even if a clean reboot attempt times out. Note that the RebootWatchdogSec= timeout applies only to the second phase of the reboot, i.e. after all regular services are already terminated, and after the system and service manager process (PID 1) got replaced by the systemd-shutdown binary, see system bootup(7) for details. During the first phase of the shutdown operation the system and service manager remains running and hence RuntimeWatchdogSec= is still honoured. In order to define a timeout on this first phase of system shutdown, configure JobTimeoutSec= and JobTimeoutAction= in the [Unit] section of the shutdown.target unit. By default RuntimeWatchdogSec= defaults to 0 (off), and RebootWatchdogSec= to 10min. KExecWatchdogSec= may be used to additionally enable the watchdog when kexec is being executed rather than when rebooting. Note that if the kernel does not reset the watchdog on kexec (depending on the specific hardware and/or driver), in this case the watchdog might not get disabled after kexec succeeds and thus the system might get rebooted, unless RuntimeWatchdogSec= is also enabled at the same time. For this reason it is recommended to enable KExecWatchdogSec= only if RuntimeWatchdogSec= is also enabled. These settings have no effect if a hardware watchdog is not available.

WatchdogDevice=

Configure the hardware watchdog device that the runtime and shutdown watchdog timers will open and use. Defaults to /dev/watchdog. This setting has no effect if a hardware watchdog is not available.

CapabilityBoundingSet=

Controls which capabilities to include in the capability bounding set for PID 1 and its children. See capabilities(7) for details. Takes a whitespace-separated list of capability names as read by cap_from_name(3). Capabilities listed will be included in the bounding set, all others are removed. If the list of capabilities is prefixed with ~, all but the listed capabilities will be included, the effect of the assignment inverted. Note that this option also affects the respective capabilities in the effective, permitted and inheritable capability sets. The capability bounding set may also be individually configured for units using the CapabilityBoundingSet= directive for units, but note that capabilities dropped for PID 1 cannot be regained in individual units, they are lost for good.

NoNewPrivileges=

Takes a boolean argument. If true, ensures that PID 1 and all its children can never gain new privileges through execve(2) (e.g. via setuid or setgid bits, or filesystem capabilities). Defaults to false. General purpose distributions commonly rely on executables with setuid or setgid bits and will thus not function properly with this option enabled. Individual units cannot disable this option. Also see No New Privileges Flag[1].

SystemCallArchitectures=

Takes a space-separated list of architecture identifiers. Selects from which architectures system calls may be invoked on this system. This may be used as an effective way to disable invocation of non-native binaries system-wide, for example to prohibit execution of 32-bit x86 binaries on 64-bit x86-64 systems. This option operates system-wide, and acts similar to the SystemCallArchitectures= setting of unit files, see systemd.exec(5) for details. This setting defaults to the empty list, in which case no filtering of system calls based on architecture is applied. Known architecture identifiers are "x86", "x86-64", "x32", "arm" and the special identifier "native". The latter implicitly maps to the native architecture of the system (or more specifically, the architecture the system manager was compiled for). Set this setting to "native" to prohibit execution of any non-native binaries. When a binary executes a system call of an architecture that is not listed in this setting, it will be immediately terminated with the SIGSYS signal.

TimerSlackNSec=

Sets the timer slack in nanoseconds for PID 1, which is inherited by all executed processes, unless overridden individually, for example with the TimerSlackNSec= setting in service units (for details see systemd.exec(5)). The timer slack controls the accuracy of wake-ups triggered by system timers. See prctl(2) for more information. Note that in contrast to most other time span definitions this parameter takes an integer value in nano-seconds if no unit is specified. The usual time units are understood too.

StatusUnitFormat=

Takes name, description or combined as the value. If name, the system manager will use unit names in status messages (e.g. "systemd-journald.service"), instead of the longer and more informative descriptions set with Description= (e.g. "Journal Logging Service"). If combined, the system manager will use both unit names and descriptions in status messages (e.g. "systemd-journald.service - Journal Logging Service"). See systemd.unit(5) for details about unit names and Description=.

DefaultTimerAccuracySec=

Sets the default accuracy of timer units. This controls the global default for the AccuracySec= setting of timer units, see systemd.timer(5) for details. AccuracySec= set in individual units override the global default for the specific unit. Defaults to 1min. Note that the accuracy of timer units is also affected by the configured timer slack for PID 1, see TimerSlackNSec= above.

DefaultTimeoutStartSec=, DefaultTimeoutStopSec=, DefaultTimeoutAbortSec=, DefaultRestartSec=

Configures the default timeouts for starting, stopping and aborting of units, as well as the default time to sleep between automatic restarts of units, as configured per-unit in TimeoutStartSec=, TimeoutStopSec=, TimeoutAbortSec= and RestartSec= (for services, see systemd.service(5) for details on the per-unit settings). Disabled by default, when service with Type=oneshot is used. For non-service units, DefaultTimeoutStartSec= sets the default TimeoutSec= value. DefaultTimeoutStartSec= and DefaultTimeoutStopSec= default to 90s. DefaultTimeoutAbortSec= is not set by default so that all units fall back to TimeoutStopSec=. DefaultRestartSec= defaults to 100ms.

DefaultStartLimitIntervalSec=, DefaultStartLimitBurst=

Configure the default unit start rate limiting, as configured per-service by StartLimitIntervalSec= and StartLimitBurst=. See systemd.service(5) for details on the per-service settings. DefaultStartLimitIntervalSec= defaults to 10s. DefaultStartLimitBurst= defaults to 5.

DefaultEnvironment=

Configures environment variables passed to all executed processes. Takes a space-separated list of variable assignments. See environ(7) for details about environment variables. Simple "%"-specifier expansion is supported, see below for a list of supported specifiers.

Example:

```
DefaultEnvironment="VAR1=word1 word2" VAR2=word3 "VAR3=word 5 6"
```

Sets three variables "VAR1", "VAR2", "VAR3".

ManagerEnvironment=

Takes the same arguments as DefaultEnvironment=, see above. Sets environment variables just for the manager process itself. In contrast to user managers, these variables are not inherited by processes spawned by the system manager, use DefaultEnvironment= for that. Note that these variables are merged into the existing environment block. In particular, in case of the system manager, this includes variables set by the kernel based on the kernel command line. Setting environment variables for the manager process may be useful to modify its behaviour. See ENVIRONMENT[2] for a descriptions of some variables understood by systemd.

Simple "%"-specifier expansion is supported, see below for a list of supported specifiers.

DefaultCPUAccounting=, DefaultBlockIOAccounting=, DefaultMemoryAccounting=, DefaultTasksAccounting=, DefaultIOAccounting=, DefaultIPAccounting=

Configure the default resource accounting settings, as configured per-unit by CPUAccounting=, BlockIOAccounting=, MemoryAccounting=, TasksAccounting=, IOAccounting= and IPAccounting=. See systemd.resource-control(5) for details on the per-unit settings. DefaultTasksAccounting= defaults to yes, DefaultMemoryAccounting= to yes. DefaultCPUAccounting= defaults to yes if enabling CPU accounting doesn't require the CPU controller to be enabled (Linux 4.15+ using the unified hierarchy for resource control), otherwise it defaults to no. The other three settings default to no.

DefaultTasksMax=

Configure the default value for the per-unit TasksMax= setting. See systemd.resource-control(5) for details. This setting applies to all unit types that support resource control settings, with the exception of slice units. Defaults to 15% of the minimum of kernel.pid_max=, kernel.threads-max= and root cgroup pids.max. Kernel has a default value for kernel.pid_max= and an algorithm of counting in case of more than 32 cores. For example with the default kernel.pid_max=, DefaultTasksMax= defaults to 4915, but might be greater in other systems or smaller in OS containers.

DefaultLimitCPU=, DefaultLimitFSIZE=, DefaultLimitDATA=, DefaultLimitSTACK=, DefaultLimitCORE=, DefaultLimitRSS=, DefaultLimitNOFILE=, DefaultLimitAS=, DefaultLimitNPROC=, DefaultLimitMEMLOCK=, DefaultLimitLOCKS=, DefaultLimitSIGPENDING=, DefaultLimitMSGQUEUE=, DefaultLimitNICE=, DefaultLimitRTPRIO=, DefaultLimitRTTIME=

These settings control various default resource limits for processes executed by units. See setrlimit(2) for details. These settings may be overridden in individual units using the corresponding LimitXXX= directives and they accept the same parameter syntax, see systemd.exec(5) for details. Note that these resource limits are only defaults for units, they are not applied to the service manager process (i.e. PID 1) itself. Most of these settings are unset, which means the resource limits are inherited from the kernel or, if invoked in a container, from the container manager. However, the following have defaults:

•DefaultLimitNOFILE= defaults to "1024:524288".

•DefaultLimitCORE= does not have a default but it is worth mentioning that RLIMIT_CORE is set to "infinity" by PID 1 which is inherited by its children.

•Note that the service manager internally increases RLIMIT_MEMLOCK for itself, however the limit is reverted to the original value for child processes forked off.

DefaultOOMPolicy=

Configure the default policy for reacting to processes being killed by the Linux Out-Of-Memory (OOM) killer. This may be used to pick a global default for the per-unit OOMPolicy= setting. See systemd.service(5) for details. Note that this default is not used for services that have Delegate= turned on.

## SPECIFIERS
Specifiers may be used in the DefaultEnvironment= and ManagerEnvironment= settings. The following expansions are understood:

Table 1. Specifiers available

Specifier

Meaning

Details

"%a"

Architecture

A short string identifying the architecture of the local system. A string such as x86, x86-64 or arm64. See the architectures defined for ConditionArchitecture= in systemd.unit(5) for a full list.

"%A"

Operating system image version

The operating system image version identifier of the running system, as read from the IMAGE_VERSION= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%b"

Boot ID

The boot ID of the running system, formatted as string. See random(4) for more information.

"%B"

Operating system build ID

The operating system build identifier of the running system, as read from the BUILD_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%H"

Host name

The hostname of the running system.

"%l"

Short host name

The hostname of the running system, truncated at the first dot to remove any domain component.

"%m"

Machine ID

The machine ID of the running system, formatted as string. See machine-id(5) for more information.

"%M"

Operating system image identifier

The operating system image identifier of the running system, as read from the IMAGE_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%o"

Operating system ID

The operating system identifier of the running system, as read from the ID= field of /etc/os-release. See os-release(5) for more information.

"%v"

Kernel release

Identical to uname -r output.

"%w"

Operating system version ID

The operating system version identifier of the running system, as read from the VERSION_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%W"

Operating system variant ID

The operating system variant identifier of the running system, as read from the VARIANT_ID= field of /etc/os-release. If not set, resolves to an empty string. See os-release(5) for more information.

"%T"

Directory for temporary files

This is either /tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)

"%V"

Directory for larger and persistent temporary files

This is either /var/tmp or the path "$TMPDIR", "$TEMP" or "$TMP" are set to. (Note that the directory may be specified without a trailing slash.)

"%%"

Single percent sign

Use "%%" in place of "%" to specify a single percent sign.

## SEE ALSO
systemd(1),

systemd.directives(7), systemd.exec(5), systemd.service(5), environ(7), capabilities(7)

## NOTES
1.

No New Privileges Flag

https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html

2.

ENVIRONMENT

https://systemd.io/ENVIRONMENT


systemd.automount

title: systemd.automount(5)

summary: Automount unit configuration

text:
# systemd.automount(5)

## NAME
systemd.automount - Automount unit configuration

## SYNOPSIS
automount.automount

## DESCRIPTION
A unit configuration file whose name ends in ".automount" encodes information about a file system automount point controlled and supervised by systemd.

This man page lists the configuration options specific to this unit type. See systemd.unit(5) for the common options of all unit configuration files. The common configuration items are configured in the generic [Unit] and [Install] sections. The automount specific configuration options are configured in the [Automount] section.

Automount units must be named after the automount directories they control. Example: the automount point /home/lennart must be configured in a unit file home-lennart.automount. For details about the escaping logic used to convert a file system path to a unit name see systemd.unit(5). Note that automount units cannot be templated, nor is it possible to add multiple names to an automount unit by creating additional symlinks to its unit file.

For each automount unit file a matching mount unit file (see systemd.mount(5) for details) must exist which is activated when the automount path is accessed. Example: if an automount unit home-lennart.automount is active and the user accesses /home/lennart the mount unit home-lennart.mount will be activated.

Automount units may be used to implement on-demand mounting as well as parallelized mounting of file systems.

Note that automount units are separate from the mount itself, so you should not set After= or Requires= for mount dependencies here. For example, you should not set After=network-online.target or similar on network filesystems. Doing so may result in an ordering cycle.

Note that automount support on Linux is privileged, automount units are hence only available in the system service manager (and root's user service manager), but not in unprivileged user's service manager.

## AUTOMATIC DEPENDENCIES

### Implicit Dependencies
The following dependencies are implicitly added:

•If an automount unit is beneath another mount unit in the file system hierarchy, both a requirement and an ordering dependency between both units are created automatically.

•An implicit Before= dependency is created between an automount unit and the mount unit it activates.

### Default Dependencies
The following dependencies are added unless DefaultDependencies=no is set:

•Automount units acquire automatic Before= and Conflicts= on umount.target in order to be stopped during shutdown.

•Automount units automatically gain an After= dependency on local-fs-pre.target, and a Before= dependency on local-fs.target.

## FSTAB
Automount units may either be configured via unit files, or via /etc/fstab (see fstab(5) for details).

For details how systemd parses /etc/fstab see systemd.mount(5).

If an automount point is configured in both /etc/fstab and a unit file, the configuration in the latter takes precedence.

## OPTIONS
Automount files must include an [Automount] section, which carries information about the file system automount points it supervises. The options specific to the [Automount] section of automount units are the following:

Where=

Takes an absolute path of a directory of the automount point. If the automount point does not exist at time that the automount point is installed, it is created. This string must be reflected in the unit filename. (See above.) This option is mandatory.

DirectoryMode=

Directories of automount points (and any parent directories) are automatically created if needed. This option specifies the file system access mode used when creating these directories. Takes an access mode in octal notation. Defaults to 0755.

TimeoutIdleSec=

Configures an idle timeout. Once the mount has been idle for the specified time, systemd will attempt to unmount. Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass 0 to disable the timeout logic. The timeout is disabled by default.

## SEE ALSO
systemd(1), systemctl(1), systemd.unit(5), systemd.mount(5), mount(8), automount(8), systemd.directives(7)