diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml index 7c0ba8cb8b..580da9d75f 100644 --- a/man/systemd-system.conf.xml +++ b/man/systemd-system.conf.xml @@ -64,11 +64,9 @@ Options - All options are configured in the - [Manager] section: + All options are configured in the [Manager] section: - LogColor= LogLevel= @@ -105,6 +103,65 @@ + + StatusUnitFormat= + + Takes , or + as the value. If , 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 , the system manager will use both unit names + and descriptions in status messages (e.g. systemd-journald.service - Journal Logging + Service). + + See + systemd.unit5 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.timer5 + 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. + + + + + + + + Resource Management + + + + 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.exec5). + The timer slack controls the accuracy of wake-ups triggered by + system timers. See + prctl2 + 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. + + + CPUAffinity= @@ -143,355 +200,6 @@ - - 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), or the special strings - off or default. If set to off - (alternatively: 0) the watchdog logic is disabled: no watchdog device is opened, - configured, or pinged. If set to the special string default the watchdog is opened - and pinged in regular intervals, but the timeout is not changed from the default. If set to any other - time value the watchdog timeout is configured to the specified value (or a value close to it, - depending on hardware capabilities). - - If RuntimeWatchdogSec= is set to a non-zero value, the watchdog hardware - (/dev/watchdog0 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 - bootup7 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. - - - - - - RuntimeWatchdogPreSec= - - Configure the hardware watchdog device pre-timeout value. - Takes a timeout value in seconds (or in other time units similar to - RuntimeWatchdogSec=). A watchdog pre-timeout is a - notification generated by the watchdog before the watchdog reset might - occur in the event the watchdog has not been serviced. This notification - is handled by the kernel and can be configured to take an action (i.e. - generate a kernel panic) using RuntimeWatchdogPreGovernor=. - Not all watchdog hardware or drivers support generating a pre-timeout and - depending on the state of the system, the kernel may be unable to take the - configured action before the watchdog reboot. The watchdog will be configured - to generate the pre-timeout event at the amount of time specified by - RuntimeWatchdogPreSec= before the runtime watchdog timeout - (set by RuntimeWatchdogSec=). For example, if the we have - RuntimeWatchdogSec=30 and - RuntimeWatchdogPreSec=10, then the pre-timeout event - will occur if the watchdog has not pinged for 20s (10s before the - watchdog would fire). By default, RuntimeWatchdogPreSec= - defaults to 0 (off). The value set for RuntimeWatchdogPreSec= - must be smaller than the timeout value for RuntimeWatchdogSec=. - This setting has no effect if a hardware watchdog is not available or the - hardware watchdog does not support a pre-timeout and will be ignored by the - kernel if the setting is greater than the actual watchdog timeout. - - - - - - RuntimeWatchdogPreGovernor= - - Configure the action taken by the hardware watchdog device - when the pre-timeout expires. The default action for the pre-timeout event - depends on the kernel configuration, but it is usually to log a kernel - message. For a list of valid actions available for a given watchdog device, - check the content of the - /sys/class/watchdog/watchdogX/pretimeout_available_governors - file. Typically, available governor types are noop and panic. - Availability, names and functionality might vary depending on the specific device driver - in use. If the pretimeout_available_governors sysfs file is empty, - the governor might be built as a kernel module and might need to be manually loaded - (e.g. pretimeout_noop.ko), or the watchdog device might not support - pre-timeouts. - - - - - - WatchdogDevice= - - Configure the hardware watchdog device that the - runtime and shutdown watchdog timers will open and use. Defaults - to /dev/watchdog0. 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 - capabilities7 - for details. Takes a whitespace-separated list of capability - names as read by - cap_from_name3. - 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 - execve2 - (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. - - - - - - - ProtectSystem= - - Takes a boolean argument or the string auto. If set to true this - will remount /usr/ read-only. If set to auto (the default) - and running in an initrd equivalent to true, otherwise false. This implements a restricted subset of - the per-unit setting of the same name, see - systemd.exec5 for - details: currently, the full or strict values are not - supported. - - - - - - 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.exec5 - 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.exec5). - The timer slack controls the accuracy of wake-ups triggered by - system timers. See - prctl2 - 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 , or - as the value. If , 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 , the system manager will use both unit names - and descriptions in status messages (e.g. systemd-journald.service - Journal Logging - Service). - - See - systemd.unit5 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.timer5 - 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.service5 - for details on the per-unit settings). For non-service units, - DefaultTimeoutStartSec= sets the default TimeoutSec= value. - - - DefaultTimeoutStartSec= and DefaultTimeoutStopSec= - default to &DEFAULT_TIMEOUT; in the system manager and &DEFAULT_USER_TIMEOUT; in the user manager. - DefaultTimeoutAbortSec= is not set by default so that all units fall back to - TimeoutStopSec=. DefaultRestartSec= defaults to 100 ms. - - - - - - - DefaultDeviceTimeoutSec= - - Configures the default timeout for waiting for devices. It can be changed per - device via the x-systemd.device-timeout= option in /etc/fstab - and /etc/crypttab (see - systemd.mount5, - crypttab5). - Defaults to &DEFAULT_TIMEOUT; in the system manager and &DEFAULT_USER_TIMEOUT; in the user manager. - - - - - - - DefaultStartLimitIntervalSec= - DefaultStartLimitBurst= - - Configure the default unit start rate - limiting, as configured per-service by - StartLimitIntervalSec= and - StartLimitBurst=. See - systemd.service5 - 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 environ7 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 for the manager process itself. These variables are inherited by processes - spawned by user managers, but not 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. - As with DefaultEnvironment=, this environment block is internal, and changes are not - reflected in the manager's /proc/PID/environ. - - Setting environment variables for the manager process may be useful to modify its behaviour. - See Known Environment Variables for a - descriptions of some variables understood by systemd. - - Simple %-specifier expansion is supported, see below for a list of supported - specifiers. - - - - - DefaultCPUAccounting= DefaultMemoryAccounting= @@ -608,6 +316,227 @@ + + DefaultMemoryPressureWatch= + DefaultMemoryPressureThresholdSec= + + Configures the default settings for the per-unit + MemoryPressureWatch= and MemoryPressureThresholdSec= + settings. See + systemd.resource-control5 + for details. Defaults to auto and 200ms, respectively. This + also sets the memory pressure monitoring threshold for the service manager itself. + + + + + + + + Hardware Watchdog + + + + 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), or the special strings + off or default. If set to off + (alternatively: 0) the watchdog logic is disabled: no watchdog device is opened, + configured, or pinged. If set to the special string default the watchdog is opened + and pinged in regular intervals, but the timeout is not changed from the default. If set to any other + time value the watchdog timeout is configured to the specified value (or a value close to it, + depending on hardware capabilities). + + If RuntimeWatchdogSec= is set to a non-zero value, the watchdog hardware + (/dev/watchdog0 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 + bootup7 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. + + + + + + RuntimeWatchdogPreSec= + + Configure the hardware watchdog device pre-timeout value. + Takes a timeout value in seconds (or in other time units similar to + RuntimeWatchdogSec=). A watchdog pre-timeout is a + notification generated by the watchdog before the watchdog reset might + occur in the event the watchdog has not been serviced. This notification + is handled by the kernel and can be configured to take an action (i.e. + generate a kernel panic) using RuntimeWatchdogPreGovernor=. + Not all watchdog hardware or drivers support generating a pre-timeout and + depending on the state of the system, the kernel may be unable to take the + configured action before the watchdog reboot. The watchdog will be configured + to generate the pre-timeout event at the amount of time specified by + RuntimeWatchdogPreSec= before the runtime watchdog timeout + (set by RuntimeWatchdogSec=). For example, if the we have + RuntimeWatchdogSec=30 and + RuntimeWatchdogPreSec=10, then the pre-timeout event + will occur if the watchdog has not pinged for 20s (10s before the + watchdog would fire). By default, RuntimeWatchdogPreSec= + defaults to 0 (off). The value set for RuntimeWatchdogPreSec= + must be smaller than the timeout value for RuntimeWatchdogSec=. + This setting has no effect if a hardware watchdog is not available or the + hardware watchdog does not support a pre-timeout and will be ignored by the + kernel if the setting is greater than the actual watchdog timeout. + + + + + + RuntimeWatchdogPreGovernor= + + Configure the action taken by the hardware watchdog device + when the pre-timeout expires. The default action for the pre-timeout event + depends on the kernel configuration, but it is usually to log a kernel + message. For a list of valid actions available for a given watchdog device, + check the content of the + /sys/class/watchdog/watchdogX/pretimeout_available_governors + file. Typically, available governor types are noop and panic. + Availability, names and functionality might vary depending on the specific device driver + in use. If the pretimeout_available_governors sysfs file is empty, + the governor might be built as a kernel module and might need to be manually loaded + (e.g. pretimeout_noop.ko), or the watchdog device might not support + pre-timeouts. + + + + + + WatchdogDevice= + + Configure the hardware watchdog device that the + runtime and shutdown watchdog timers will open and use. Defaults + to /dev/watchdog0. This setting has no + effect if a hardware watchdog is not available. + + + + + + + + Security + + + + CapabilityBoundingSet= + + Controls which capabilities to include in the + capability bounding set for PID 1 and its children. See + capabilities7 + for details. Takes a whitespace-separated list of capability + names as read by + cap_from_name3. + 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 + execve2 + (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. + + + + + + + ProtectSystem= + + Takes a boolean argument or the string auto. If set to true this + will remount /usr/ read-only. If set to auto (the default) + and running in an initrd equivalent to true, otherwise false. This implements a restricted subset of + the per-unit setting of the same name, see + systemd.exec5 for + details: currently, the full or strict values are not + supported. + + + + + + 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.exec5 + 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. + + + + DefaultSmackProcessLabel= @@ -621,6 +550,67 @@ + + + + + Timeouts and Rate Limits + + + + 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.service5 + for details on the per-unit settings). For non-service units, + DefaultTimeoutStartSec= sets the default TimeoutSec= value. + + + DefaultTimeoutStartSec= and DefaultTimeoutStopSec= + default to &DEFAULT_TIMEOUT; in the system manager and &DEFAULT_USER_TIMEOUT; in the user manager. + DefaultTimeoutAbortSec= is not set by default so that all units fall back to + TimeoutStopSec=. DefaultRestartSec= defaults to 100 ms. + + + + + + + DefaultDeviceTimeoutSec= + + Configures the default timeout for waiting for devices. It can be changed per + device via the x-systemd.device-timeout= option in /etc/fstab + and /etc/crypttab (see + systemd.mount5, + crypttab5). + Defaults to &DEFAULT_TIMEOUT; in the system manager and &DEFAULT_USER_TIMEOUT; in the user manager. + + + + + + + DefaultStartLimitIntervalSec= + DefaultStartLimitBurst= + + Configure the default unit start rate + limiting, as configured per-service by + StartLimitIntervalSec= and + StartLimitBurst=. See + systemd.service5 + for details on the per-service settings. + DefaultStartLimitIntervalSec= defaults to + 10s. DefaultStartLimitBurst= defaults to + 5. + + + ReloadLimitIntervalSec= @@ -635,19 +625,56 @@ + + + + + Environment + + + + ManagerEnvironment= + + Takes the same arguments as DefaultEnvironment=, see above. Sets + environment variables for the manager process itself. These variables are inherited by processes + spawned by user managers, but not 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. + As with DefaultEnvironment=, this environment block is internal, and changes are not + reflected in the manager's /proc/PID/environ. + + Setting environment variables for the manager process may be useful to modify its behaviour. + See Known Environment Variables for a + descriptions of some variables understood by systemd. + + Simple %-specifier expansion is supported, see below for a list of supported + specifiers. + + + + - DefaultMemoryPressureWatch= - DefaultMemoryPressureThresholdSec= + DefaultEnvironment= - Configures the default settings for the per-unit - MemoryPressureWatch= and MemoryPressureThresholdSec= - settings. See - systemd.resource-control5 - for details. Defaults to auto and 200ms, respectively. This - also sets the memory pressure monitoring threshold for the service manager itself. + Configures environment variables passed to all executed processes. Takes a + space-separated list of variable assignments. See environ7 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. + +