systemd-ts 0.1.0 → 0.1.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +59 -0
- package/dist/index.d.mts +849 -429
- package/package.json +2 -2
package/dist/index.d.mts
CHANGED
|
@@ -81,11 +81,35 @@ declare class SystemdTimer<const TOptions extends SystemdTimerOptions = SystemdT
|
|
|
81
81
|
}
|
|
82
82
|
//#endregion
|
|
83
83
|
//#region src/main/types.d.ts
|
|
84
|
-
type
|
|
85
|
-
type
|
|
86
|
-
type
|
|
87
|
-
type
|
|
88
|
-
type
|
|
84
|
+
type UnitActionDirectiveValue = "none" | "reboot" | "reboot-force" | "reboot-immediate" | "poweroff" | "poweroff-force" | "poweroff-immediate" | "exit" | "exit-force" | "soft-reboot" | "soft-reboot-force" | "kexec" | "kexec-force" | "halt" | "halt-force" | "halt-immediate";
|
|
85
|
+
type JobModeDirectiveValue = "fail" | "replace" | "replace-irreversibly" | "isolate" | "flush" | "ignore-dependencies" | "ignore-requirements";
|
|
86
|
+
type ServiceTypeDirectiveValue = "simple" | "exec" | "forking" | "oneshot" | "dbus" | "notify" | "notify-reload" | "idle";
|
|
87
|
+
type ServiceExitTypeDirectiveValue = "main" | "cgroup";
|
|
88
|
+
type ServiceRestartDirectiveValue = "no" | "on-success" | "on-failure" | "on-abnormal" | "on-watchdog" | "on-abort" | "always";
|
|
89
|
+
type ServiceRestartModeDirectiveValue = "normal" | "direct" | "debug";
|
|
90
|
+
type NotifyAccessDirectiveValue = "none" | "main" | "exec" | "all";
|
|
91
|
+
type OOMPolicyDirectiveValue = "continue" | "stop" | "kill";
|
|
92
|
+
type FileDescriptorStorePreserveDirectiveValue = boolean | "restart";
|
|
93
|
+
type TimeoutFailureModeDirectiveValue = "terminate" | "abort" | "kill";
|
|
94
|
+
type KeyringModeDirectiveValue = "inherit" | "private" | "shared";
|
|
95
|
+
type IOSchedulingClassDirectiveValue = "realtime" | "best-effort" | "idle";
|
|
96
|
+
type MountPropagationDirectiveValue = "shared" | "slave" | "private";
|
|
97
|
+
type DevicePolicyDirectiveValue = "auto" | "closed" | "strict";
|
|
98
|
+
type CPUSchedulingPolicyDirectiveValue = "other" | "batch" | "idle" | "fifo" | "rr" | "ext";
|
|
99
|
+
type SyslogFacilityDirectiveValue = "kern" | "user" | "mail" | "daemon" | "auth" | "syslog" | "lpr" | "news" | "uucp" | "cron" | "authpriv" | "ftp" | "local0" | "local1" | "local2" | "local3" | "local4" | "local5" | "local6" | "local7";
|
|
100
|
+
type SyslogLevelDirectiveValue = "emerg" | "alert" | "crit" | "err" | "warning" | "notice" | "info" | "debug";
|
|
101
|
+
type MemoryTHPDirectiveValue = "inherit" | "disable" | "madvise" | "system";
|
|
102
|
+
type ProcSubsetDirectiveValue = "all" | "pid";
|
|
103
|
+
type ProtectProcDirectiveValue = "noaccess" | "invisible" | "ptraceable" | "default";
|
|
104
|
+
type UtmpModeDirectiveValue = "init" | "login" | "user";
|
|
105
|
+
type ProcessResourceLimitDirectiveValue = number | "infinity" | `${string}:${string}` | (string & {});
|
|
106
|
+
type ManagedOOMDirectiveValue = "auto" | "kill";
|
|
107
|
+
type ManagedOOMPreferenceDirectiveValue = "none" | "avoid" | "omit";
|
|
108
|
+
type StandardInputDirectiveValue = "null" | "tty" | "tty-force" | "tty-fail" | "data" | "socket" | "fd" | `file:${string}` | `fd:${string}`;
|
|
109
|
+
type StandardOutputDirectiveValue = "inherit" | "null" | "tty" | "journal" | "kmsg" | "journal+console" | "kmsg+console" | "socket" | "fd" | `file:${string}` | `append:${string}` | `truncate:${string}` | `fd:${string}`;
|
|
110
|
+
type StandardErrorDirectiveValue = StandardOutputDirectiveValue | "inherit";
|
|
111
|
+
type ExecDirective = string | Executable | readonly (string | Executable)[];
|
|
112
|
+
type UnitValue = string | number | boolean | Executable;
|
|
89
113
|
type UnitValueList = readonly UnitValue[];
|
|
90
114
|
type UnitSectionValue = UnitValue | UnitValueList | undefined;
|
|
91
115
|
interface CustomDirectiveSection {
|
|
@@ -94,454 +118,850 @@ interface CustomDirectiveSection {
|
|
|
94
118
|
/**
|
|
95
119
|
* Generic unit-level directives shared by service and timer units.
|
|
96
120
|
*
|
|
121
|
+
* References in this file are grounded in cached upstream systemd v260.1 manpages.
|
|
122
|
+
*
|
|
97
123
|
* Sources:
|
|
98
|
-
* -
|
|
99
|
-
* - https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
|
|
124
|
+
* - systemd v260.1, `systemd.unit(5)`
|
|
100
125
|
*/
|
|
101
126
|
interface SystemdUnitSection extends CustomDirectiveSection {
|
|
102
|
-
|
|
103
|
-
readonly
|
|
104
|
-
|
|
105
|
-
readonly
|
|
106
|
-
|
|
107
|
-
readonly
|
|
108
|
-
|
|
109
|
-
readonly
|
|
110
|
-
|
|
111
|
-
readonly
|
|
112
|
-
|
|
113
|
-
readonly
|
|
114
|
-
|
|
115
|
-
readonly
|
|
116
|
-
|
|
117
|
-
readonly
|
|
118
|
-
|
|
119
|
-
readonly
|
|
120
|
-
|
|
121
|
-
readonly
|
|
122
|
-
|
|
123
|
-
readonly
|
|
124
|
-
|
|
125
|
-
readonly
|
|
126
|
-
|
|
127
|
-
readonly
|
|
128
|
-
|
|
129
|
-
readonly
|
|
130
|
-
|
|
131
|
-
readonly
|
|
132
|
-
|
|
133
|
-
readonly
|
|
134
|
-
|
|
135
|
-
readonly
|
|
136
|
-
|
|
137
|
-
readonly
|
|
138
|
-
|
|
139
|
-
readonly
|
|
140
|
-
|
|
141
|
-
readonly
|
|
142
|
-
|
|
143
|
-
readonly
|
|
144
|
-
|
|
145
|
-
readonly
|
|
146
|
-
|
|
147
|
-
readonly
|
|
148
|
-
|
|
149
|
-
readonly
|
|
150
|
-
|
|
151
|
-
readonly
|
|
152
|
-
|
|
153
|
-
readonly
|
|
154
|
-
|
|
155
|
-
readonly
|
|
156
|
-
|
|
157
|
-
readonly
|
|
158
|
-
|
|
159
|
-
readonly
|
|
160
|
-
|
|
161
|
-
readonly
|
|
162
|
-
|
|
163
|
-
readonly
|
|
164
|
-
|
|
165
|
-
readonly
|
|
166
|
-
|
|
167
|
-
readonly
|
|
168
|
-
|
|
169
|
-
readonly
|
|
170
|
-
|
|
171
|
-
readonly
|
|
172
|
-
|
|
173
|
-
readonly
|
|
174
|
-
|
|
175
|
-
readonly
|
|
176
|
-
|
|
177
|
-
readonly
|
|
178
|
-
|
|
179
|
-
readonly
|
|
180
|
-
|
|
181
|
-
readonly
|
|
182
|
-
|
|
183
|
-
readonly
|
|
184
|
-
|
|
185
|
-
readonly
|
|
186
|
-
|
|
187
|
-
readonly
|
|
188
|
-
|
|
189
|
-
readonly
|
|
190
|
-
|
|
191
|
-
readonly
|
|
192
|
-
|
|
193
|
-
readonly
|
|
194
|
-
|
|
195
|
-
readonly
|
|
196
|
-
|
|
197
|
-
readonly
|
|
198
|
-
|
|
199
|
-
readonly
|
|
200
|
-
|
|
201
|
-
readonly
|
|
202
|
-
|
|
203
|
-
readonly
|
|
204
|
-
|
|
205
|
-
readonly
|
|
206
|
-
|
|
207
|
-
readonly
|
|
208
|
-
|
|
209
|
-
readonly
|
|
210
|
-
|
|
211
|
-
readonly
|
|
212
|
-
|
|
213
|
-
readonly
|
|
214
|
-
|
|
215
|
-
readonly
|
|
127
|
+
/** Units that should be ordered before this unit starts. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
128
|
+
readonly After?: string | readonly string[];
|
|
129
|
+
/** If true, this unit may be used with the systemctl isolate command. Otherwise, this will be refused. It probably is a good idea to leave this disabled except for target units that shall be used similar to runlevels in SysV init systems, just as a precaution to avoid unusable system states. This option defaults to false. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
130
|
+
readonly AllowIsolate?: boolean;
|
|
131
|
+
/** Assertion form of `ConditionACPower=`. Check whether the system has AC power, or is exclusively battery powered at the time of activation of the unit. If set to true, the condition will hold only if at least one AC connector of the system is connected to a power source, or if no AC connectors are known. Conversely, if set to false, the condition will hold only if there is at least one AC connector known and all AC connectors are disconnected from a power source. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
132
|
+
readonly AssertACPower?: boolean | readonly boolean[];
|
|
133
|
+
/** Assertion form of `ConditionArchitecture=`. Check whether the system is running on a specific architecture. Takes one of x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, ia64, parisc, parisc64, s390, s390x, sparc, sparc64, mips, mips-le, mips64, mips64-le, alpha, arm, arm-be, arm64, arm64-be, sh, sh64, m68k, tilegx, cris, arc, arc-be, or native. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
134
|
+
readonly AssertArchitecture?: string | readonly string[];
|
|
135
|
+
/** Assertion form of `ConditionCPUFeature=`. Verify that a given CPU feature is available via the CPUID instruction. This condition only does something on i386 and x86-64 processors. On other processors it is assumed that the CPU does not support the given feature. It checks the leaves 1, 7, 0x80000001, and 0x80000007. Valid values are: fpu, vme, de, pse, tsc, msr, pae, mce, cx8, apic, sep, mtrr, pge, mca, cmov, pat, pse36, clflush, mmx, fxsr, sse, sse2, ht, pni, pclmul, monitor, ssse3, fma3, cx16, sse4_1, sse4_2, movbe, popcnt, aes, xsave, osxsave, avx, f16c, rdrand, bmi1, avx2, bmi2, rdseed, adx, sha_ni, syscall, rdtscp, lm, lahf_lm, abm, constant_tsc. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
136
|
+
readonly AssertCPUFeature?: string | readonly string[];
|
|
137
|
+
/** Assertion form of `ConditionCPUPressure=`. Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold. This setting takes a threshold value as argument. It can be specified as a simple percentage value, suffixed with %, in which case the pressure will be measured as an average over the last five minutes before the attempt to start the unit is performed. Alternatively, the average timespan can also be specified using / as a separator, for example: 10%/1min. The supported timespans match what the kernel provides, and are limited to 10sec, 1min and 5min. The full PSI will be checked first, and if not found some will be checked. For more details, see the documentation on PSI (Pressure Stall Information) . Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
138
|
+
readonly AssertCPUPressure?: string | readonly string[];
|
|
139
|
+
/** Assertion form of `ConditionCPUs=`. Verify that the specified number of CPUs is available to the current system. Takes a number of CPUs as argument, optionally prefixed with a comparison operator <, <=, = (or ==), != (or <>), >=, >. Compares the number of CPUs in the CPU affinity mask configured of the service manager itself with the specified number, adhering to the specified comparison operator. On physical systems the number of CPUs in the affinity mask of the service manager usually matches the number of physical CPUs, but in special and virtual environments might differ. In particular, in containers the affinity mask usually matches the number of CPUs assigned to the container and not the physically available ones. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
140
|
+
readonly AssertCPUs?: string | readonly string[];
|
|
141
|
+
/** Assertion form of `ConditionCapability=`. Check whether the given capability exists in the capability bounding set of the service manager (i.e. this does not check whether capability is actually available in the permitted or effective sets, see capabilities(7) for details). Pass a capability name such as CAP_MKNOD, possibly prefixed with an exclamation mark to negate the check. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
142
|
+
readonly AssertCapability?: string | readonly string[];
|
|
143
|
+
/** Assertion form of `ConditionControlGroupController=`. Check whether given cgroup controllers (e.g. cpu) are available for use on the system or whether the legacy v1 cgroup or the modern v2 cgroup hierarchy is used. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
144
|
+
readonly AssertControlGroupController?: string | readonly string[];
|
|
145
|
+
/** Assertion form of `ConditionCredential=`. May be used to check whether a credential by the specified name was passed into the service manager. See System and Service Credentials for details about credentials. If used in services for the system service manager this may be used to conditionalize services based on system credentials passed in. If used in services for the per-user service manager this may be used to conditionalize services based on credentials passed into the unit@.service service instance belonging to the user. The argument must be a valid credential name. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
146
|
+
readonly AssertCredential?: string | readonly string[];
|
|
147
|
+
/** Assertion form of `ConditionDirectoryNotEmpty=`. Similar to `ConditionPathExists=`, but verifies that a certain path exists and is a non-empty directory. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
148
|
+
readonly AssertDirectoryNotEmpty?: string | readonly string[];
|
|
149
|
+
/** Assertion form of `ConditionEnvironment=`. May be used to check whether a specific environment variable is set (or if prefixed with the exclamation mark — unset) in the service manager's environment block. The argument may be a single word, to check if the variable with this name is defined in the environment block, or an assignment (name=value), to check if the variable with this exact value is defined. Note that the environment block of the service manager itself is checked, i.e. not any variables defined with Environment= or EnvironmentFile=, as described above. This is particularly useful when the service manager runs inside a containerized environment or as per-user service manager, in order to check for variables passed in by the enclosing container manager or PAM. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
150
|
+
readonly AssertEnvironment?: string | readonly string[];
|
|
151
|
+
/** Assertion form of `ConditionFileIsExecutable=`. Similar to `ConditionPathExists=`, but verifies that a certain path exists, is a regular file, and marked executable. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
152
|
+
readonly AssertFileIsExecutable?: string | readonly string[];
|
|
153
|
+
/** Assertion form of `ConditionFileNotEmpty=`. Similar to `ConditionPathExists=`, but verifies that a certain path exists and refers to a regular file with a non-zero size. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
154
|
+
readonly AssertFileNotEmpty?: string | readonly string[];
|
|
155
|
+
/** Assertion form of `ConditionFirstBoot=`. This condition may be used to conditionalize units on whether the system is booting up for the first time. This roughly means that /etc/ was unpopulated when the system started booting (for details, see "First Boot Semantics" in machine-id(5)). First Boot is considered finished (this condition will evaluate as false) after the manager has finished the startup phase. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
156
|
+
readonly AssertFirstBoot?: boolean | readonly boolean[];
|
|
157
|
+
/** Assertion form of `ConditionGroup=`. Similar to `ConditionUser=`, but verifies that the service manager's real or effective group, or any of its auxiliary groups, match the specified group or GID. This setting does not support the special value @system. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
158
|
+
readonly AssertGroup?: string | readonly string[];
|
|
159
|
+
/** Assertion form of `ConditionHost=`. May be used to match against the hostname, machine ID, boot ID or product UUID of the host. This either takes a hostname string (optionally with shell style globs) which is tested against the locally set hostname as returned by gethostname2, or a 128bit ID or UUID, formatted as string. The latter is compared against machine ID, boot ID and the firmware product UUID if there is any. See machine-id(5) for details about the machine ID. The test may be negated by prepending an exclamation mark. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
160
|
+
readonly AssertHost?: string | readonly string[];
|
|
161
|
+
/** Assertion form of `ConditionIOPressure=`. Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold. This setting takes a threshold value as argument. It can be specified as a simple percentage value, suffixed with %, in which case the pressure will be measured as an average over the last five minutes before the attempt to start the unit is performed. Alternatively, the average timespan can also be specified using / as a separator, for example: 10%/1min. The supported timespans match what the kernel provides, and are limited to 10sec, 1min and 5min. The full PSI will be checked first, and if not found some will be checked. For more details, see the documentation on PSI (Pressure Stall Information) . Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
162
|
+
readonly AssertIOPressure?: string | readonly string[];
|
|
163
|
+
/** Assertion form of `ConditionKernelCommandLine=`. May be used to check whether a specific kernel command line option is set (or if prefixed with the exclamation mark — unset). The argument must either be a single word, or an assignment (i.e. two words, separated by =). In the former case the kernel command line is searched for the word appearing as is, or as left hand side of an assignment. In the latter case, the exact assignment is looked for with right and left hand side matching. This operates on the kernel command line communicated to userspace via /proc/cmdline, except when the service manager is invoked as payload of a container manager, in which case the command line of PID 1 is used instead (i.e. /proc/1/cmdline). Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
164
|
+
readonly AssertKernelCommandLine?: string | readonly string[];
|
|
165
|
+
/** Assertion form of `ConditionKernelModuleLoaded=`. Test whether the specified kernel module has been loaded and is already fully initialized. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
166
|
+
readonly AssertKernelModuleLoaded?: string | readonly string[];
|
|
167
|
+
/** Assertion form of `ConditionKernelVersion=`. May be used to check whether the kernel version (as reported by uname -r) matches a certain expression, or if prefixed with the exclamation mark, does not match. The argument must be a list of (potentially quoted) expressions. Each expression starts with one of = or != for string comparisons, <, <=, ==, <>, >=, > for version comparisons, or $=, !$= for a shell-style glob match. If no operator is specified, $= is implied. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
168
|
+
readonly AssertKernelVersion?: string | readonly string[];
|
|
169
|
+
/** Assertion form of `ConditionMemory=`. Verify that the specified amount of system memory is available to the current system. Takes a memory size in bytes as argument, optionally prefixed with a comparison operator <, <=, = (or ==), != (or <>), >=, >. On bare-metal systems compares the amount of physical memory in the system with the specified size, adhering to the specified comparison operator. In containers compares the amount of memory assigned to the container instead. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
170
|
+
readonly AssertMemory?: number | string | readonly (number | string)[];
|
|
171
|
+
/** Assertion form of `ConditionMemoryPressure=`. Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold. This setting takes a threshold value as argument. It can be specified as a simple percentage value, suffixed with %, in which case the pressure will be measured as an average over the last five minutes before the attempt to start the unit is performed. Alternatively, the average timespan can also be specified using / as a separator, for example: 10%/1min. The supported timespans match what the kernel provides, and are limited to 10sec, 1min and 5min. The full PSI will be checked first, and if not found some will be checked. For more details, see the documentation on PSI (Pressure Stall Information) . Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
172
|
+
readonly AssertMemoryPressure?: string | readonly string[];
|
|
173
|
+
/** Assertion form of `ConditionNeedsUpdate=`. Takes one of /var/ or /etc/ as argument, possibly prefixed with a ! (to invert the condition). This condition may be used to conditionalize units on whether the specified directory requires an update because /usr/'s modification time is newer than the stamp file .updated in the specified directory. This is useful to implement offline updates of the vendor operating system resources in /usr/ that require updating of /etc/ or /var/ on the next following boot. Units making use of this condition should order themselves before systemd-update-done.service8, to make sure they run before the stamp file's modification time gets reset indicating a completed update. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
174
|
+
readonly AssertNeedsUpdate?: string | readonly string[];
|
|
175
|
+
/** Assertion form of `ConditionOSRelease=`. Verify that a specific key=value pair is set in the host's os-release5. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
176
|
+
readonly AssertOSRelease?: string | readonly string[];
|
|
177
|
+
/** Assertion form of `ConditionPathExists=`. Check for the existence of a file. If the specified absolute path name does not exist, the condition will fail. If the absolute path name passed to ConditionPathExists= is prefixed with an exclamation mark (!), the test is negated, and the unit is only started if the path does not exist. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
178
|
+
readonly AssertPathExists?: string | readonly string[];
|
|
179
|
+
/** Assertion form of `ConditionPathExistsGlob=`. Similar to `ConditionPathExists=`, but checks for the existence of at least one file or directory matching the specified globbing pattern. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
180
|
+
readonly AssertPathExistsGlob?: string | readonly string[];
|
|
181
|
+
/** Assertion form of `ConditionPathIsDirectory=`. Similar to `ConditionPathExists=`, but verifies that a certain path exists and is a directory. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
182
|
+
readonly AssertPathIsDirectory?: string | readonly string[];
|
|
183
|
+
/** Assertion form of `ConditionPathIsEncrypted=`. Similar to `ConditionPathExists=`, but verifies that the underlying file system's backing block device is encrypted using dm-crypt/LUKS. Note that this check does not cover ext4 per-directory encryption, and only detects block level encryption. Moreover, if the specified path resides on a file system on top of a loopback block device, only encryption above the loopback device is detected. It is not detected whether the file system backing the loopback block device is encrypted. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
184
|
+
readonly AssertPathIsEncrypted?: string | readonly string[];
|
|
185
|
+
/** Assertion form of `ConditionPathIsMountPoint=`. Similar to `ConditionPathExists=`, but verifies that a certain path exists and is a mount point. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
186
|
+
readonly AssertPathIsMountPoint?: string | readonly string[];
|
|
187
|
+
/** Assertion form of `ConditionPathIsReadWrite=`. Similar to `ConditionPathExists=`, but verifies that the underlying file system is readable and writable (i.e. not mounted read-only). Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
188
|
+
readonly AssertPathIsReadWrite?: string | readonly string[];
|
|
189
|
+
/** Assertion form of `ConditionPathIsSocket=`. Similar to `ConditionPathExists=`, but verifies that a certain path exists and is a socket. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
190
|
+
readonly AssertPathIsSocket?: string | readonly string[];
|
|
191
|
+
/** Assertion form of `ConditionPathIsSymbolicLink=`. Similar to `ConditionPathExists=`, but verifies that a certain path exists and is a symbolic link. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
192
|
+
readonly AssertPathIsSymbolicLink?: string | readonly string[];
|
|
193
|
+
/** Assertion form of `ConditionSecurity=`. May be used to check whether the given security technology is enabled on the system. Currently, the following values are recognized:. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
194
|
+
readonly AssertSecurity?: string | readonly string[];
|
|
195
|
+
/** Assertion form of `ConditionUser=`. Takes a numeric UID, a UNIX user name, or the special value @system. This condition may be used to check whether the service manager is running as the given user. The special value @system can be used to check if the user id is within the system user range. This option is not useful for system services, as the system manager exclusively runs as the root user, and thus the test result is constant. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
196
|
+
readonly AssertUser?: string | readonly string[];
|
|
197
|
+
/** Assertion form of `ConditionVersion=`. May be used to check whether a software version matches a certain expression, or if prefixed with the exclamation mark, does not match. The first argument is the software whose version has to be checked. Currently kernel, systemd and glibc are supported. If this argument is omitted, kernel is implied. The second argument must be a list of (potentially quoted) expressions. Each expression starts with one of = or != for string comparisons, <, <=, ==, <>, >=, > for version comparisons, or $=, !$= for a shell-style glob match. If no operator is specified, $= is implied. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
198
|
+
readonly AssertVersion?: string | readonly string[];
|
|
199
|
+
/** Assertion form of `ConditionVirtualization=`. Check whether the system is executed in a virtualized environment and optionally test whether it is a specific implementation. Takes either boolean value to check if being executed in any virtualized environment, or one of vm and container to test against a generic type of virtualization solution, or one of qemu, kvm, amazon, zvm, vmware, microsoft, oracle, powervm, xen, bochs, uml, bhyve, qnx, apple, sre, openvz, lxc, lxc-libvirt, systemd-nspawn, docker, podman, rkt, wsl, proot, pouch, acrn to test against a specific implementation, or private-users to check whether we are running in a user namespace. See systemd-detect-virt1 for a full list of known virtualization technologies and their identifiers. If multiple virtualization technologies are nested, only the innermost is considered. The test may be negated by prepending an exclamation mark. Unlike conditions, a mismatch fails the start job instead of skipping it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
200
|
+
readonly AssertVirtualization?: boolean | string | readonly string[];
|
|
201
|
+
/** Units that should be ordered after this unit starts. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
202
|
+
readonly Before?: string | readonly string[];
|
|
203
|
+
/** Configures requirement dependencies, very similar in style to Requires=. However, this dependency type is stronger: in addition to the effects of Requires=, which already stops (or restarts) the configuring unit when a listed unit is explicitly stopped (or restarted), it also does so when a listed unit stops unexpectedly (which includes when it fails). Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of a mount unit might be unmounted without involvement of the system and service manager. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
204
|
+
readonly BindsTo?: string | readonly string[];
|
|
205
|
+
/** Tweaks the "garbage collection" algorithm for this unit. Takes one of inactive or inactive-or-failed. If set to inactive the unit will be unloaded if it is in the inactive state and is not referenced by clients, jobs or other units — however it is not unloaded if it is in the failed state. In failed mode, failed units are not unloaded until the user invoked systemctl reset-failed on them to reset the failed state, or an equivalent command. This behaviour is altered if this option is set to inactive-or-failed: in this case, the unit is unloaded even if the unit is in a failed state, and thus an explicitly resetting of the failed state is not necessary. Note that if this mode is used unit results (such as exit codes, exit signals, consumed resources, …) are flushed out immediately after the unit completed, except for what is stored in the logging subsystem. Defaults to inactive. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
206
|
+
readonly CollectMode?: "inactive" | "inactive-or-failed";
|
|
207
|
+
/** Check whether the system has AC power, or is exclusively battery powered at the time of activation of the unit. If set to true, the condition will hold only if at least one AC connector of the system is connected to a power source, or if no AC connectors are known. Conversely, if set to false, the condition will hold only if there is at least one AC connector known and all AC connectors are disconnected from a power source. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
208
|
+
readonly ConditionACPower?: boolean | readonly boolean[];
|
|
209
|
+
/** Check whether the system is running on a specific architecture. Takes one of x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, ia64, parisc, parisc64, s390, s390x, sparc, sparc64, mips, mips-le, mips64, mips64-le, alpha, arm, arm-be, arm64, arm64-be, sh, sh64, m68k, tilegx, cris, arc, arc-be, or native. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
210
|
+
readonly ConditionArchitecture?: string | readonly string[];
|
|
211
|
+
/** Verify that a given CPU feature is available via the CPUID instruction. This condition only does something on i386 and x86-64 processors. On other processors it is assumed that the CPU does not support the given feature. It checks the leaves 1, 7, 0x80000001, and 0x80000007. Valid values are: fpu, vme, de, pse, tsc, msr, pae, mce, cx8, apic, sep, mtrr, pge, mca, cmov, pat, pse36, clflush, mmx, fxsr, sse, sse2, ht, pni, pclmul, monitor, ssse3, fma3, cx16, sse4_1, sse4_2, movbe, popcnt, aes, xsave, osxsave, avx, f16c, rdrand, bmi1, avx2, bmi2, rdseed, adx, sha_ni, syscall, rdtscp, lm, lahf_lm, abm, constant_tsc. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
212
|
+
readonly ConditionCPUFeature?: string | readonly string[];
|
|
213
|
+
/** Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold. This setting takes a threshold value as argument. It can be specified as a simple percentage value, suffixed with %, in which case the pressure will be measured as an average over the last five minutes before the attempt to start the unit is performed. Alternatively, the average timespan can also be specified using / as a separator, for example: 10%/1min. The supported timespans match what the kernel provides, and are limited to 10sec, 1min and 5min. The full PSI will be checked first, and if not found some will be checked. For more details, see the documentation on PSI (Pressure Stall Information) . Source: systemd v260.1, `systemd.unit(5)`. */
|
|
214
|
+
readonly ConditionCPUPressure?: string | readonly string[];
|
|
215
|
+
/** Verify that the specified number of CPUs is available to the current system. Takes a number of CPUs as argument, optionally prefixed with a comparison operator <, <=, = (or ==), != (or <>), >=, >. Compares the number of CPUs in the CPU affinity mask configured of the service manager itself with the specified number, adhering to the specified comparison operator. On physical systems the number of CPUs in the affinity mask of the service manager usually matches the number of physical CPUs, but in special and virtual environments might differ. In particular, in containers the affinity mask usually matches the number of CPUs assigned to the container and not the physically available ones. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
216
|
+
readonly ConditionCPUs?: string | readonly string[];
|
|
217
|
+
/** Check whether the given capability exists in the capability bounding set of the service manager (i.e. this does not check whether capability is actually available in the permitted or effective sets, see capabilities(7) for details). Pass a capability name such as CAP_MKNOD, possibly prefixed with an exclamation mark to negate the check. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
218
|
+
readonly ConditionCapability?: string | readonly string[];
|
|
219
|
+
/** Check whether given cgroup controllers (e.g. cpu) are available for use on the system or whether the legacy v1 cgroup or the modern v2 cgroup hierarchy is used. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
220
|
+
readonly ConditionControlGroupController?: string | readonly string[];
|
|
221
|
+
/** May be used to check whether a credential by the specified name was passed into the service manager. See System and Service Credentials for details about credentials. If used in services for the system service manager this may be used to conditionalize services based on system credentials passed in. If used in services for the per-user service manager this may be used to conditionalize services based on credentials passed into the unit@.service service instance belonging to the user. The argument must be a valid credential name. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
222
|
+
readonly ConditionCredential?: string | readonly string[];
|
|
223
|
+
/** Similar to `ConditionPathExists=`, but verifies that a certain path exists and is a non-empty directory. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
224
|
+
readonly ConditionDirectoryNotEmpty?: string | readonly string[];
|
|
225
|
+
/** May be used to check whether a specific environment variable is set (or if prefixed with the exclamation mark — unset) in the service manager's environment block. The argument may be a single word, to check if the variable with this name is defined in the environment block, or an assignment (name=value), to check if the variable with this exact value is defined. Note that the environment block of the service manager itself is checked, i.e. not any variables defined with Environment= or EnvironmentFile=, as described above. This is particularly useful when the service manager runs inside a containerized environment or as per-user service manager, in order to check for variables passed in by the enclosing container manager or PAM. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
226
|
+
readonly ConditionEnvironment?: string | readonly string[];
|
|
227
|
+
/** Similar to `ConditionPathExists=`, but verifies that a certain path exists, is a regular file, and marked executable. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
228
|
+
readonly ConditionFileIsExecutable?: string | readonly string[];
|
|
229
|
+
/** Similar to `ConditionPathExists=`, but verifies that a certain path exists and refers to a regular file with a non-zero size. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
230
|
+
readonly ConditionFileNotEmpty?: string | readonly string[];
|
|
231
|
+
/** Check whether the system's firmware is of a certain type. The following values are possible:. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
232
|
+
readonly ConditionFirmware?: string | readonly string[];
|
|
233
|
+
/** This condition may be used to conditionalize units on whether the system is booting up for the first time. This roughly means that /etc/ was unpopulated when the system started booting (for details, see "First Boot Semantics" in machine-id(5)). First Boot is considered finished (this condition will evaluate as false) after the manager has finished the startup phase. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
234
|
+
readonly ConditionFirstBoot?: boolean | readonly boolean[];
|
|
235
|
+
/** Similar to `ConditionUser=`, but verifies that the service manager's real or effective group, or any of its auxiliary groups, match the specified group or GID. This setting does not support the special value @system. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
236
|
+
readonly ConditionGroup?: string | readonly string[];
|
|
237
|
+
/** May be used to match against the hostname, machine ID, boot ID or product UUID of the host. This either takes a hostname string (optionally with shell style globs) which is tested against the locally set hostname as returned by gethostname2, or a 128bit ID or UUID, formatted as string. The latter is compared against machine ID, boot ID and the firmware product UUID if there is any. See machine-id(5) for details about the machine ID. The test may be negated by prepending an exclamation mark. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
238
|
+
readonly ConditionHost?: string | readonly string[];
|
|
239
|
+
/** Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold. This setting takes a threshold value as argument. It can be specified as a simple percentage value, suffixed with %, in which case the pressure will be measured as an average over the last five minutes before the attempt to start the unit is performed. Alternatively, the average timespan can also be specified using / as a separator, for example: 10%/1min. The supported timespans match what the kernel provides, and are limited to 10sec, 1min and 5min. The full PSI will be checked first, and if not found some will be checked. For more details, see the documentation on PSI (Pressure Stall Information) . Source: systemd v260.1, `systemd.unit(5)`. */
|
|
240
|
+
readonly ConditionIOPressure?: string | readonly string[];
|
|
241
|
+
/** May be used to check whether a specific kernel command line option is set (or if prefixed with the exclamation mark — unset). The argument must either be a single word, or an assignment (i.e. two words, separated by =). In the former case the kernel command line is searched for the word appearing as is, or as left hand side of an assignment. In the latter case, the exact assignment is looked for with right and left hand side matching. This operates on the kernel command line communicated to userspace via /proc/cmdline, except when the service manager is invoked as payload of a container manager, in which case the command line of PID 1 is used instead (i.e. /proc/1/cmdline). Source: systemd v260.1, `systemd.unit(5)`. */
|
|
242
|
+
readonly ConditionKernelCommandLine?: string | readonly string[];
|
|
243
|
+
/** Test whether the specified kernel module has been loaded and is already fully initialized. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
244
|
+
readonly ConditionKernelModuleLoaded?: string | readonly string[];
|
|
245
|
+
/** May be used to check whether the kernel version (as reported by uname -r) matches a certain expression, or if prefixed with the exclamation mark, does not match. The argument must be a list of (potentially quoted) expressions. Each expression starts with one of = or != for string comparisons, <, <=, ==, <>, >=, > for version comparisons, or $=, !$= for a shell-style glob match. If no operator is specified, $= is implied. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
246
|
+
readonly ConditionKernelVersion?: string | readonly string[];
|
|
247
|
+
/** Verify that the specified amount of system memory is available to the current system. Takes a memory size in bytes as argument, optionally prefixed with a comparison operator <, <=, = (or ==), != (or <>), >=, >. On bare-metal systems compares the amount of physical memory in the system with the specified size, adhering to the specified comparison operator. In containers compares the amount of memory assigned to the container instead. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
248
|
+
readonly ConditionMemory?: number | string | readonly (number | string)[];
|
|
249
|
+
/** Verify that the overall system (memory, CPU or IO) pressure is below or equal to a threshold. This setting takes a threshold value as argument. It can be specified as a simple percentage value, suffixed with %, in which case the pressure will be measured as an average over the last five minutes before the attempt to start the unit is performed. Alternatively, the average timespan can also be specified using / as a separator, for example: 10%/1min. The supported timespans match what the kernel provides, and are limited to 10sec, 1min and 5min. The full PSI will be checked first, and if not found some will be checked. For more details, see the documentation on PSI (Pressure Stall Information) . Source: systemd v260.1, `systemd.unit(5)`. */
|
|
250
|
+
readonly ConditionMemoryPressure?: string | readonly string[];
|
|
251
|
+
/** Takes one of /var/ or /etc/ as argument, possibly prefixed with a ! (to invert the condition). This condition may be used to conditionalize units on whether the specified directory requires an update because /usr/'s modification time is newer than the stamp file .updated in the specified directory. This is useful to implement offline updates of the vendor operating system resources in /usr/ that require updating of /etc/ or /var/ on the next following boot. Units making use of this condition should order themselves before systemd-update-done.service8, to make sure they run before the stamp file's modification time gets reset indicating a completed update. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
252
|
+
readonly ConditionNeedsUpdate?: string | readonly string[];
|
|
253
|
+
/** Verify that a specific key=value pair is set in the host's os-release5. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
254
|
+
readonly ConditionOSRelease?: string | readonly string[];
|
|
255
|
+
/** Check for the existence of a file. If the specified absolute path name does not exist, the condition will fail. If the absolute path name passed to ConditionPathExists= is prefixed with an exclamation mark (!), the test is negated, and the unit is only started if the path does not exist. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
256
|
+
readonly ConditionPathExists?: string | readonly string[];
|
|
257
|
+
/** Similar to `ConditionPathExists=`, but checks for the existence of at least one file or directory matching the specified globbing pattern. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
258
|
+
readonly ConditionPathExistsGlob?: string | readonly string[];
|
|
259
|
+
/** Similar to `ConditionPathExists=`, but verifies that a certain path exists and is a directory. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
260
|
+
readonly ConditionPathIsDirectory?: string | readonly string[];
|
|
261
|
+
/** Similar to `ConditionPathExists=`, but verifies that the underlying file system's backing block device is encrypted using dm-crypt/LUKS. Note that this check does not cover ext4 per-directory encryption, and only detects block level encryption. Moreover, if the specified path resides on a file system on top of a loopback block device, only encryption above the loopback device is detected. It is not detected whether the file system backing the loopback block device is encrypted. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
262
|
+
readonly ConditionPathIsEncrypted?: string | readonly string[];
|
|
263
|
+
/** Similar to `ConditionPathExists=`, but verifies that a certain path exists and is a mount point. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
264
|
+
readonly ConditionPathIsMountPoint?: string | readonly string[];
|
|
265
|
+
/** Similar to `ConditionPathExists=`, but verifies that the underlying file system is readable and writable (i.e. not mounted read-only). Source: systemd v260.1, `systemd.unit(5)`. */
|
|
266
|
+
readonly ConditionPathIsReadWrite?: string | readonly string[];
|
|
267
|
+
/** Similar to `ConditionPathExists=`, but verifies that a certain path exists and is a socket. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
268
|
+
readonly ConditionPathIsSocket?: string | readonly string[];
|
|
269
|
+
/** Similar to `ConditionPathExists=`, but verifies that a certain path exists and is a symbolic link. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
270
|
+
readonly ConditionPathIsSymbolicLink?: string | readonly string[];
|
|
271
|
+
/** May be used to check whether the given security technology is enabled on the system. Currently, the following values are recognized:. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
272
|
+
readonly ConditionSecurity?: string | readonly string[];
|
|
273
|
+
/** Takes a numeric UID, a UNIX user name, or the special value @system. This condition may be used to check whether the service manager is running as the given user. The special value @system can be used to check if the user id is within the system user range. This option is not useful for system services, as the system manager exclusively runs as the root user, and thus the test result is constant. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
274
|
+
readonly ConditionUser?: string | readonly string[];
|
|
275
|
+
/** May be used to check whether a software version matches a certain expression, or if prefixed with the exclamation mark, does not match. The first argument is the software whose version has to be checked. Currently kernel, systemd and glibc are supported. If this argument is omitted, kernel is implied. The second argument must be a list of (potentially quoted) expressions. Each expression starts with one of = or != for string comparisons, <, <=, ==, <>, >=, > for version comparisons, or $=, !$= for a shell-style glob match. If no operator is specified, $= is implied. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
276
|
+
readonly ConditionVersion?: string | readonly string[];
|
|
277
|
+
/** Check whether the system is executed in a virtualized environment and optionally test whether it is a specific implementation. Takes either boolean value to check if being executed in any virtualized environment, or one of vm and container to test against a generic type of virtualization solution, or one of qemu, kvm, amazon, zvm, vmware, microsoft, oracle, powervm, xen, bochs, uml, bhyve, qnx, apple, sre, openvz, lxc, lxc-libvirt, systemd-nspawn, docker, podman, rkt, wsl, proot, pouch, acrn to test against a specific implementation, or private-users to check whether we are running in a user namespace. See systemd-detect-virt1 for a full list of known virtualization technologies and their identifiers. If multiple virtualization technologies are nested, only the innermost is considered. The test may be negated by prepending an exclamation mark. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
278
|
+
readonly ConditionVirtualization?: boolean | string | readonly string[];
|
|
279
|
+
/** A space-separated list of unit names. Configures negative requirement dependencies. If a unit has a Conflicts= requirement on a set of other units, then starting it will stop all of them and starting any of them will stop it. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
280
|
+
readonly Conflicts?: string | readonly string[];
|
|
281
|
+
/** If yes, (the default), a few default dependencies will implicitly be created for the unit. The actual dependencies created depend on the unit type. For example, for service units, these dependencies ensure that the service is started only after basic system initialization is completed and is properly terminated on system shutdown. See the respective man pages for details. Generally, only services involved with early boot or late shutdown should set this option to no. It is highly recommended to leave this option enabled for the majority of common units. If set to no, this option does not disable all implicit dependencies, just non-essential ones. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
282
|
+
readonly DefaultDependencies?: boolean;
|
|
283
|
+
/** A brief, meaningful, human-readable text identifying the unit. This may be used by systemd (and suitable UIs) as a user-visible label for the unit, so this string should identify the unit rather than just describe it, despite the name. This string also should not just repeat the unit name. Apache HTTP Server or Postfix Mail Server are good examples. Bad examples are high-performance lightweight HTTP server (too generic) or Apache (meaningless for people who do not know the Apache HTTP server project, duplicates the unit name). systemd may use this string as a noun in status messages (Starting Description..., Started Description., Reached target Description., Failed to start Description.), so it should be capitalized, and should not be a full sentence, or a phrase with a verb conjugated in the present continuous, or end in a full stop. Bad examples include exiting the container, updating the database once per day., or OpenSSH server second instance daemon. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
284
|
+
readonly Description?: string;
|
|
285
|
+
/** A space-separated list of URIs referencing documentation for this unit or its configuration. Accepted are only URIs of the types http://, https://, file:, info:, man:. For more information about the syntax of these URIs, see uri(7). The URIs should be listed in order of relevance, starting with the most relevant. It is a good idea to first reference documentation that explains what the unit's purpose is, followed by how it is configured, followed by any other related documentation. This option may be specified more than once, in which case the specified list of URIs is merged. If the empty string is assigned to this option, the list is reset and all prior assignments will have no effect. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
286
|
+
readonly Documentation?: string | readonly string[];
|
|
287
|
+
/** Action to take when the unit stops in a failed state. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
288
|
+
readonly FailureAction?: UnitActionDirectiveValue;
|
|
289
|
+
/** Exit status to propagate when `FailureAction=` triggers `exit` or `exit-force`. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
290
|
+
readonly FailureActionExitStatus?: string | number;
|
|
291
|
+
/** If true, this unit will not be stopped when isolating another unit. Defaults to false for service, target, socket, timer, and path units, and true for slice, scope, device, swap, mount, and automount units. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
292
|
+
readonly IgnoreOnIsolate?: boolean;
|
|
293
|
+
/** Timeout that starts once the queued job actually begins running. If it expires, the job is cancelled without changing the unit state. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
294
|
+
readonly JobRunningTimeoutSec?: number | string;
|
|
295
|
+
/** Extra action to take when `JobTimeoutSec=` or `JobRunningTimeoutSec=` expires. Uses the same action values as `FailureAction=` and `SuccessAction=`. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
296
|
+
readonly JobTimeoutAction?: UnitActionDirectiveValue;
|
|
297
|
+
/** Optional reboot argument to pass when `JobTimeoutAction=` performs a reboot-style action. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
298
|
+
readonly JobTimeoutRebootArgument?: string;
|
|
299
|
+
/** Timeout for the whole queued job, starting when the job is first enqueued. If it expires, the job is cancelled without changing the unit state. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
300
|
+
readonly JobTimeoutSec?: number | string;
|
|
301
|
+
/** For units that start processes (such as service units), lists one or more other units whose network and/or temporary file namespace to join. If this is specified on a unit (say, a.service has JoinsNamespaceOf=b.service), then the inverse dependency (JoinsNamespaceOf=a.service for b.service) is implied. This only applies to unit types which support the PrivateNetwork=, NetworkNamespacePath=, PrivateIPC=, IPCNamespacePath=, and PrivateTmp= directives (see systemd.exec5 for details). If a unit that has this setting set is started, its processes will see the same /tmp/, /var/tmp/, IPC namespace and network namespace as one listed unit that is started. If multiple listed units are already started and these do not share their namespace, then it is not defined which namespace is joined. Note that this setting only has an effect if PrivateNetwork=/NetworkNamespacePath=, PrivateIPC=/IPCNamespacePath= and/or PrivateTmp= is enabled for both the unit that joins the namespace and the unit whose namespace is joined. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
302
|
+
readonly JoinsNamespaceOf?: string | readonly string[];
|
|
303
|
+
/** A space-separated list of one or more units that are activated when this unit enters the failed state. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
304
|
+
readonly OnFailure?: string | readonly string[];
|
|
305
|
+
/** Job mode used when enqueuing units listed in `OnFailure=`. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
306
|
+
readonly OnFailureJobMode?: JobModeDirectiveValue;
|
|
307
|
+
/** A space-separated list of one or more units that are activated when this unit enters the inactive state. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
308
|
+
readonly OnSuccess?: string | readonly string[];
|
|
309
|
+
/** Job mode used when enqueuing units listed in `OnSuccess=`. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
310
|
+
readonly OnSuccessJobMode?: JobModeDirectiveValue;
|
|
311
|
+
/** Configures dependencies similar to Requires=, but limited to stopping and restarting of units. When systemd stops or restarts the units listed here, the action is propagated to this unit. Note that this is a one-way dependency — changes to this unit do not affect the listed units. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
312
|
+
readonly PartOf?: string | readonly string[];
|
|
313
|
+
/** Units that should receive reload requests when this unit is reloaded. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
314
|
+
readonly PropagatesReloadTo?: string | readonly string[];
|
|
315
|
+
/** Units that should receive stop requests when this unit is stopped. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
316
|
+
readonly PropagatesStopTo?: string | readonly string[];
|
|
317
|
+
/** Configure the optional argument for the reboot2 system call if StartLimitAction= or FailureAction= is a reboot action. This works just like the optional argument to systemctl reboot command. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
318
|
+
readonly RebootArgument?: string;
|
|
319
|
+
/** If true, this unit can only be activated or deactivated indirectly. In this case, explicit start-up or termination requested by the user is denied, however if it is started or stopped as a dependency of another unit, start-up or termination will succeed. This is mostly a safety feature to ensure that the user does not accidentally activate units that are not intended to be activated explicitly, and not accidentally deactivate units that are not intended to be deactivated. These options default to false. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
320
|
+
readonly RefuseManualStart?: boolean;
|
|
321
|
+
/** If true, this unit can only be activated or deactivated indirectly. In this case, explicit start-up or termination requested by the user is denied, however if it is started or stopped as a dependency of another unit, start-up or termination will succeed. This is mostly a safety feature to ensure that the user does not accidentally activate units that are not intended to be activated explicitly, and not accidentally deactivate units that are not intended to be deactivated. These options default to false. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
322
|
+
readonly RefuseManualStop?: boolean;
|
|
323
|
+
/** Units whose reload requests should also reload this unit. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
324
|
+
readonly ReloadPropagatedFrom?: string | readonly string[];
|
|
325
|
+
/** Similar to Wants=, but declares a stronger requirement dependency. Dependencies of this type may also be configured by adding a symlink to a .requires/ directory accompanying the unit file. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
326
|
+
readonly Requires?: string | readonly string[];
|
|
327
|
+
/** Takes a space-separated list of absolute paths. Automatically adds dependencies of type Requires= and After= for all mount units required to access the specified path. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
328
|
+
readonly RequiresMountsFor?: string | readonly string[];
|
|
329
|
+
/** Similar to Requires=. However, if the units listed here are not started already, they will not be started and the starting of this unit will fail immediately. Requisite= does not imply an ordering dependency, even if both units are started in the same transaction. Hence this setting should usually be combined with After=, to ensure this unit is not started before the other unit. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
330
|
+
readonly Requisite?: string | readonly string[];
|
|
331
|
+
/** A path to a configuration file this unit has been generated from. This is primarily useful for implementation of generator tools that convert configuration from an external configuration file format into native unit files. This functionality should not be used in normal units. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
332
|
+
readonly SourcePath?: string;
|
|
333
|
+
/** Configure an additional action to take if the rate limit configured with StartLimitIntervalSec= and StartLimitBurst= is hit. Takes the same values as the FailureAction=/SuccessAction= settings. If none is set, hitting the rate limit will trigger no action except that the start will not be permitted. Defaults to none. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
334
|
+
readonly StartLimitAction?: UnitActionDirectiveValue;
|
|
335
|
+
/** See systemd.unit(5) for StartLimitBurst=. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
336
|
+
readonly StartLimitBurst?: number;
|
|
337
|
+
/** Configure unit start rate limiting. Units which are started more than burst times within an interval time span are not permitted to start any more. Use StartLimitIntervalSec= to configure the checking interval and StartLimitBurst= to configure how many starts per interval are allowed. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
338
|
+
readonly StartLimitIntervalSec?: number | string;
|
|
339
|
+
/** Units whose stop requests should also stop this unit. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
340
|
+
readonly StopPropagatedFrom?: string | readonly string[];
|
|
341
|
+
/** If true, this unit will be stopped when it is no longer used. Note that, in order to minimize the work to be executed, systemd will not stop units by default unless they are conflicting with other units, or the user explicitly requested their shut down. If this option is set, a unit will be automatically cleaned up if no other active unit requires it. Defaults to false. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
342
|
+
readonly StopWhenUnneeded?: boolean;
|
|
343
|
+
/** Action to take when the unit stops in an inactive state. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
344
|
+
readonly SuccessAction?: UnitActionDirectiveValue;
|
|
345
|
+
/** Exit status to propagate when `SuccessAction=` triggers `exit` or `exit-force`. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
346
|
+
readonly SuccessActionExitStatus?: string | number;
|
|
347
|
+
/** Defaults to no. If yes, processes belonging to this unit will not be sent the final SIGTERM and SIGKILL signals during the final phase of the system shutdown process. This functionality replaces the older mechanism that allowed a program to set argv[0][0] = '@' as described at systemd and Storage Daemons for the Root File System, which however continues to be supported. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
348
|
+
readonly SurviveFinalKillSignal?: boolean;
|
|
349
|
+
/** Configures dependencies similar to Wants=, but as long as this unit is up, all units listed in Upholds= are started whenever found to be inactive or failed, and no job is queued for them. While a Wants= dependency on another unit has a one-time effect when this units started, a Upholds= dependency on it has a continuous effect, constantly restarting the unit if necessary. This is an alternative to the Restart= setting of service units, to ensure they are kept running whatever happens. The restart happens without delay, and usual per-unit rate-limit applies. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
350
|
+
readonly Upholds?: string | readonly string[];
|
|
351
|
+
/** Configures (weak) requirement dependencies on other units. This option may be specified more than once or multiple space-separated units may be specified in one option in which case dependencies for all listed names will be created. Dependencies of this type may also be configured outside of the unit configuration file by adding a symlink to a .wants/ directory accompanying the unit file. For details, see above. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
352
|
+
readonly Wants?: string | readonly string[];
|
|
353
|
+
/** Same as RequiresMountsFor=, but adds dependencies of type Wants= instead of Requires=. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
354
|
+
readonly WantsMountsFor?: string | readonly string[];
|
|
216
355
|
}
|
|
217
356
|
/**
|
|
218
357
|
* Install-time directives interpreted by `systemctl enable` rather than the
|
|
219
358
|
* service manager during normal unit execution.
|
|
220
359
|
*
|
|
221
360
|
* Sources:
|
|
222
|
-
* -
|
|
223
|
-
* - https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
|
|
361
|
+
* - systemd v260.1, `systemd.unit(5)`
|
|
224
362
|
*/
|
|
225
363
|
interface SystemdInstallSection extends CustomDirectiveSection {
|
|
226
|
-
|
|
227
|
-
readonly
|
|
228
|
-
|
|
229
|
-
readonly
|
|
230
|
-
|
|
231
|
-
readonly
|
|
364
|
+
/** A space-separated list of additional names this unit shall be installed under. The names listed here must have the same suffix (i.e. type) as the unit filename. This option may be specified more than once, in which case all listed names are used. At installation time, systemctl enable will create symlinks from these names to the unit filename. Note that not all unit types support such alias names, and this setting is not supported for them. Specifically, mount, slice, swap, and automount units do not support aliasing. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
365
|
+
readonly Alias?: string | readonly string[];
|
|
366
|
+
/** Additional units to install/deinstall when this unit is installed/deinstalled. If the user requests installation/deinstallation of a unit with this option configured, systemctl enable and systemctl disable will automatically install/uninstall units listed in this option as well. This option may be specified more than once, or as a space-separated list of unit names. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
367
|
+
readonly Also?: string | readonly string[];
|
|
368
|
+
/** In template unit files, this specifies for which instance the unit shall be enabled if the template is enabled without any explicitly set instance. This option has no effect in non-template unit files. The specified string must be usable as instance identifier. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
369
|
+
readonly DefaultInstance?: string;
|
|
370
|
+
/** Enable-time reverse `Requires=` relationship: enabling this unit creates `.requires/` links from the listed units to it. This option may be specified more than once, or as a space-separated list of unit names. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
371
|
+
readonly RequiredBy?: string | readonly string[];
|
|
372
|
+
/** Enable-time reverse `Upholds=` relationship: enabling this unit creates `.upholds/` links from the listed units to it. This option may be specified more than once, or as a space-separated list of unit names. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
373
|
+
readonly UpheldBy?: string | readonly string[];
|
|
374
|
+
/** Enable-time reverse `Wants=` relationship: enabling this unit creates `.wants/` links from the listed units to it. This option may be specified more than once, or as a space-separated list of unit names. Source: systemd v260.1, `systemd.unit(5)`. */
|
|
375
|
+
readonly WantedBy?: string | readonly string[];
|
|
232
376
|
}
|
|
233
377
|
/**
|
|
234
378
|
* Timer-specific directives for `[Timer]` sections.
|
|
235
379
|
*
|
|
236
380
|
* Sources:
|
|
237
|
-
* -
|
|
238
|
-
* - https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
|
|
381
|
+
* - systemd v260.1, `systemd.timer(5)`
|
|
239
382
|
*/
|
|
240
383
|
interface SystemdTimerSection extends CustomDirectiveSection {
|
|
241
|
-
|
|
242
|
-
readonly
|
|
243
|
-
|
|
244
|
-
readonly
|
|
245
|
-
|
|
246
|
-
readonly
|
|
247
|
-
|
|
248
|
-
readonly
|
|
249
|
-
|
|
250
|
-
readonly
|
|
251
|
-
|
|
252
|
-
readonly
|
|
253
|
-
|
|
254
|
-
readonly
|
|
255
|
-
|
|
256
|
-
readonly
|
|
257
|
-
|
|
384
|
+
/** Specify the accuracy the timer shall elapse with. Defaults to 1min. The timer is scheduled to elapse within a time window starting with the time specified in OnCalendar=, OnActiveSec=, OnBootSec=, OnStartupSec=, OnUnitActiveSec= or OnUnitInactiveSec= and ending the time configured with AccuracySec= later. Within this time window, the expiry time will be placed at a host-specific, randomized, but stable position that is synchronized between all local timer units. This is done in order to optimize power consumption to suppress unnecessary CPU wake-ups. To get best accuracy, set this option to 1us. Note that the timer is still subject to the timer slack configured via systemd-system.conf(5)'s TimerSlackNSec= setting. See prctl(2) for details. To optimize power consumption, make sure to set this value as high as possible and as low as necessary. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
385
|
+
readonly AccuracySec?: number | string;
|
|
386
|
+
/** When enabled, the timer schedules the next elapse based on the trigger unit entering inactivity, instead of the last trigger time. This is most apparent in the case where the service unit takes longer to run than the timer interval. With this setting enabled, the timer will schedule the next elapse based on when the service finishes running, and so it will have to wait until the next realtime elapse time to trigger. Otherwise, the default behavior is for the timer unit to immediately trigger again once the service finishes running. This happens because the timer schedules the next elapse based on the previous trigger time, and since the interval is shorter than the service runtime, that elapse will be in the past, causing it to immediately trigger once done. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
387
|
+
readonly DeferReactivation?: boolean;
|
|
388
|
+
/** When enabled, the randomized delay specified by RandomizedDelaySec= is chosen deterministically, and remains stable between all firings of the same timer, even if the manager is restarted. The delay is derived from the machine ID, the manager's user identifier, and the timer unit's name. This effectively creates a unique fixed offset for each timer, reducing the jitter in firings of an individual timer while still avoiding firing at the same time as other similarly configured timers. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
389
|
+
readonly FixedRandomDelay?: boolean;
|
|
390
|
+
/** Defines a timer relative to when the timer unit itself is activated. May be specified more than once, and may be combined with other timer expressions. Assigning the empty string resets the full timer expression list. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
391
|
+
readonly OnActiveSec?: number | string | readonly (number | string)[];
|
|
392
|
+
/** Defines a timer relative to machine boot; in containers this is mapped to OnStartupSec= for the system manager. May be specified more than once, and may be combined with other timer expressions. Assigning the empty string resets the full timer expression list. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
393
|
+
readonly OnBootSec?: number | string | readonly (number | string)[];
|
|
394
|
+
/** Defines realtime (i.e. wallclock) timers with calendar event expressions. See systemd.time(7) for more information on the syntax of calendar event expressions. Otherwise, the semantics are similar to OnActiveSec= and related settings. May be specified more than once, and may be combined with monotonic timer expressions. Assigning the empty string resets the full timer expression list. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
395
|
+
readonly OnCalendar?: string | readonly string[];
|
|
396
|
+
/** Triggers the associated unit when CLOCK_REALTIME jumps relative to CLOCK_MONOTONIC. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
397
|
+
readonly OnClockChange?: boolean;
|
|
398
|
+
/** Defines a timer relative to when the service manager first started, which is especially useful in per-user managers. May be specified more than once, and may be combined with other timer expressions. Assigning the empty string resets the full timer expression list. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
399
|
+
readonly OnStartupSec?: number | string | readonly (number | string)[];
|
|
400
|
+
/** Triggers the associated unit when the local system timezone changes. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
401
|
+
readonly OnTimezoneChange?: boolean;
|
|
402
|
+
/** Defines a timer relative to when the triggered unit was last activated. May be specified more than once, and may be combined with other timer expressions. Assigning the empty string resets the full timer expression list. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
403
|
+
readonly OnUnitActiveSec?: number | string | readonly (number | string)[];
|
|
404
|
+
/** Defines a timer relative to when the triggered unit was last deactivated. May be specified more than once, and may be combined with other timer expressions. Assigning the empty string resets the full timer expression list. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
405
|
+
readonly OnUnitInactiveSec?: number | string | readonly (number | string)[];
|
|
406
|
+
/** Stores the last trigger time on disk so a missed `OnCalendar=` firing can be caught up when the timer becomes active again. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
407
|
+
readonly Persistent?: boolean;
|
|
408
|
+
/** Delay the timer by a randomly selected, evenly distributed amount of time between 0 and the specified time value. Defaults to 0, indicating that no randomized delay shall be applied. Each timer unit will determine this delay randomly before each iteration, unless modified with FixedRandomDelay=, see below. The delay is added on top of the next determined elapsing time or the service manager's startup time, whichever is later. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
409
|
+
readonly RandomizedDelaySec?: number | string;
|
|
410
|
+
/** Offsets the timer by a stable, randomly-selected, and evenly distributed amount of time between 0 and the specified time value. Defaults to 0, indicating that no such offset shall be applied. The offset is chosen deterministically, and is derived the same way as FixedRandomDelay=, see above. The offset is added on top of the next determined elapsing time. This setting only has an effect on timers configured with OnCalendar=, and it can be combined with RandomizedDelaySec=. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
411
|
+
readonly RandomizedOffsetSec?: number | string;
|
|
412
|
+
/** If true, a timer will stay loaded, and its state remains queryable even after it elapsed and the associated unit (as configured with Unit=, see above) deactivated again. If false, an elapsed timer unit that cannot elapse anymore is unloaded once its associated unit deactivated again. Turning this off is particularly useful for transient timer units. Note that this setting has an effect when repeatedly starting a timer unit: if RemainAfterElapse= is on, starting the timer a second time has no effect. However, if RemainAfterElapse= is off and the timer unit was already unloaded, it can be started again, and thus the service can be triggered multiple times. Defaults to true. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
413
|
+
readonly RemainAfterElapse?: boolean;
|
|
414
|
+
/** The unit to activate when this timer elapses. The argument is a unit name, whose suffix is not .timer. If not specified, this value defaults to a service that has the same name as the timer unit, except for the suffix. (See above.) It is recommended that the unit name that is activated and the unit name of the timer unit are named identically, except for the suffix. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
415
|
+
readonly Unit?: string;
|
|
416
|
+
/** If true, an elapsing timer will cause the system to resume from suspend, should it be suspended and if the system supports this. Note that this option will only make sure the system resumes on the appropriate times, it will not take care of suspending it again after any work that is to be done is finished. Defaults to false. Source: systemd v260.1, `systemd.timer(5)`. */
|
|
417
|
+
readonly WakeSystem?: boolean;
|
|
258
418
|
}
|
|
259
419
|
/**
|
|
260
420
|
* Service-specific and shared execution directives for `[Service]` sections.
|
|
261
421
|
*
|
|
262
|
-
* This interface includes
|
|
263
|
-
*
|
|
264
|
-
*
|
|
265
|
-
* - kill-behaviour directives from `systemd.kill(5)`
|
|
266
|
-
* - resource-control directives from `systemd.resource-control(5)`
|
|
267
|
-
*
|
|
268
|
-
* Sources:
|
|
269
|
-
* - https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html
|
|
270
|
-
* - https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html
|
|
271
|
-
* - https://www.freedesktop.org/software/systemd/man/latest/systemd.kill.html
|
|
272
|
-
* - https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html
|
|
273
|
-
* - https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
|
|
422
|
+
* This interface includes directives from `systemd.service(5)`,
|
|
423
|
+
* `systemd.exec(5)`, `systemd.kill(5)`, and
|
|
424
|
+
* `systemd.resource-control(5)` as of systemd v260.1.
|
|
274
425
|
*/
|
|
275
426
|
interface SystemdServiceSection extends CustomDirectiveSection {
|
|
276
|
-
|
|
277
|
-
readonly
|
|
278
|
-
|
|
279
|
-
readonly
|
|
280
|
-
|
|
281
|
-
readonly
|
|
282
|
-
|
|
283
|
-
readonly
|
|
284
|
-
|
|
285
|
-
readonly
|
|
286
|
-
|
|
287
|
-
readonly
|
|
288
|
-
|
|
289
|
-
readonly
|
|
290
|
-
|
|
291
|
-
readonly
|
|
292
|
-
|
|
293
|
-
readonly
|
|
294
|
-
|
|
295
|
-
readonly
|
|
296
|
-
|
|
297
|
-
readonly
|
|
298
|
-
|
|
299
|
-
readonly
|
|
300
|
-
|
|
301
|
-
readonly
|
|
302
|
-
|
|
303
|
-
readonly
|
|
304
|
-
|
|
305
|
-
readonly
|
|
306
|
-
|
|
307
|
-
readonly
|
|
308
|
-
|
|
309
|
-
readonly
|
|
310
|
-
|
|
311
|
-
readonly
|
|
312
|
-
|
|
313
|
-
readonly
|
|
314
|
-
|
|
315
|
-
readonly
|
|
316
|
-
|
|
317
|
-
readonly
|
|
318
|
-
|
|
319
|
-
readonly
|
|
320
|
-
|
|
321
|
-
readonly
|
|
322
|
-
|
|
323
|
-
readonly
|
|
324
|
-
|
|
325
|
-
readonly
|
|
326
|
-
|
|
327
|
-
readonly
|
|
328
|
-
|
|
329
|
-
readonly
|
|
330
|
-
|
|
331
|
-
readonly
|
|
332
|
-
|
|
333
|
-
readonly
|
|
334
|
-
|
|
335
|
-
readonly
|
|
336
|
-
|
|
337
|
-
readonly
|
|
338
|
-
|
|
339
|
-
readonly
|
|
340
|
-
|
|
341
|
-
readonly
|
|
342
|
-
|
|
343
|
-
readonly
|
|
344
|
-
|
|
345
|
-
readonly
|
|
346
|
-
|
|
347
|
-
readonly
|
|
348
|
-
|
|
349
|
-
readonly
|
|
350
|
-
|
|
351
|
-
readonly
|
|
352
|
-
|
|
353
|
-
readonly
|
|
354
|
-
|
|
355
|
-
readonly
|
|
356
|
-
|
|
357
|
-
readonly
|
|
358
|
-
|
|
359
|
-
readonly
|
|
360
|
-
|
|
361
|
-
readonly
|
|
362
|
-
|
|
363
|
-
readonly
|
|
364
|
-
|
|
365
|
-
readonly
|
|
366
|
-
|
|
367
|
-
readonly
|
|
368
|
-
|
|
369
|
-
readonly
|
|
370
|
-
|
|
371
|
-
readonly
|
|
372
|
-
|
|
373
|
-
readonly
|
|
374
|
-
|
|
375
|
-
readonly
|
|
376
|
-
|
|
377
|
-
readonly
|
|
378
|
-
|
|
379
|
-
readonly
|
|
380
|
-
|
|
381
|
-
readonly
|
|
382
|
-
|
|
383
|
-
readonly
|
|
384
|
-
|
|
385
|
-
readonly
|
|
386
|
-
|
|
387
|
-
readonly
|
|
388
|
-
|
|
389
|
-
readonly
|
|
390
|
-
|
|
391
|
-
readonly
|
|
392
|
-
|
|
393
|
-
readonly
|
|
394
|
-
|
|
395
|
-
readonly
|
|
396
|
-
|
|
397
|
-
readonly
|
|
398
|
-
|
|
399
|
-
readonly
|
|
400
|
-
|
|
401
|
-
readonly
|
|
402
|
-
|
|
403
|
-
readonly
|
|
404
|
-
|
|
405
|
-
readonly
|
|
406
|
-
|
|
407
|
-
readonly
|
|
408
|
-
|
|
409
|
-
readonly
|
|
410
|
-
|
|
411
|
-
readonly
|
|
412
|
-
|
|
413
|
-
readonly
|
|
414
|
-
|
|
415
|
-
readonly
|
|
416
|
-
|
|
417
|
-
readonly
|
|
418
|
-
|
|
419
|
-
readonly
|
|
420
|
-
|
|
421
|
-
readonly
|
|
422
|
-
|
|
423
|
-
readonly
|
|
424
|
-
|
|
425
|
-
readonly
|
|
426
|
-
|
|
427
|
-
readonly
|
|
428
|
-
|
|
429
|
-
readonly
|
|
430
|
-
|
|
431
|
-
readonly
|
|
432
|
-
|
|
433
|
-
readonly
|
|
434
|
-
|
|
435
|
-
readonly
|
|
436
|
-
|
|
437
|
-
readonly
|
|
438
|
-
|
|
439
|
-
readonly
|
|
440
|
-
|
|
441
|
-
readonly
|
|
442
|
-
|
|
443
|
-
readonly
|
|
444
|
-
|
|
445
|
-
readonly
|
|
446
|
-
|
|
447
|
-
readonly
|
|
448
|
-
|
|
449
|
-
readonly
|
|
450
|
-
|
|
451
|
-
readonly
|
|
452
|
-
|
|
453
|
-
readonly
|
|
454
|
-
|
|
455
|
-
readonly
|
|
456
|
-
|
|
457
|
-
readonly
|
|
458
|
-
|
|
459
|
-
readonly
|
|
460
|
-
|
|
461
|
-
readonly
|
|
462
|
-
|
|
463
|
-
readonly
|
|
464
|
-
|
|
465
|
-
readonly
|
|
466
|
-
|
|
467
|
-
readonly
|
|
468
|
-
|
|
469
|
-
readonly
|
|
470
|
-
|
|
471
|
-
readonly
|
|
472
|
-
|
|
473
|
-
readonly
|
|
474
|
-
|
|
475
|
-
readonly
|
|
476
|
-
|
|
477
|
-
readonly
|
|
478
|
-
|
|
479
|
-
readonly
|
|
480
|
-
|
|
481
|
-
readonly
|
|
482
|
-
|
|
483
|
-
readonly
|
|
484
|
-
|
|
485
|
-
readonly
|
|
486
|
-
|
|
487
|
-
readonly
|
|
488
|
-
|
|
489
|
-
readonly
|
|
490
|
-
|
|
491
|
-
readonly
|
|
492
|
-
|
|
493
|
-
readonly
|
|
494
|
-
|
|
495
|
-
readonly
|
|
496
|
-
|
|
497
|
-
readonly
|
|
498
|
-
|
|
499
|
-
readonly
|
|
500
|
-
|
|
501
|
-
readonly
|
|
502
|
-
|
|
503
|
-
readonly
|
|
504
|
-
|
|
505
|
-
readonly
|
|
506
|
-
|
|
507
|
-
readonly
|
|
508
|
-
|
|
509
|
-
readonly
|
|
510
|
-
|
|
511
|
-
readonly
|
|
512
|
-
|
|
513
|
-
readonly
|
|
514
|
-
|
|
515
|
-
readonly
|
|
516
|
-
|
|
517
|
-
readonly
|
|
518
|
-
|
|
519
|
-
readonly
|
|
520
|
-
|
|
521
|
-
readonly
|
|
522
|
-
|
|
523
|
-
readonly
|
|
524
|
-
|
|
525
|
-
readonly
|
|
526
|
-
|
|
527
|
-
readonly
|
|
528
|
-
|
|
529
|
-
readonly
|
|
530
|
-
|
|
531
|
-
readonly
|
|
532
|
-
|
|
533
|
-
readonly
|
|
534
|
-
|
|
535
|
-
readonly
|
|
536
|
-
|
|
537
|
-
readonly
|
|
538
|
-
|
|
539
|
-
readonly
|
|
540
|
-
|
|
541
|
-
readonly
|
|
542
|
-
|
|
543
|
-
readonly
|
|
544
|
-
|
|
427
|
+
/** This setting controls the cpuset controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
428
|
+
readonly AllowedCPUs?: string;
|
|
429
|
+
/** These settings control the cpuset controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
430
|
+
readonly AllowedMemoryNodes?: string;
|
|
431
|
+
/** Controls which capabilities to include in the ambient capability set for the executed process. Takes a whitespace-separated list of capability names, e.g. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. This option may appear more than once, in which case the ambient capability sets are merged (see the above examples in CapabilityBoundingSet=). If the list of capabilities is prefixed with ~, all but the listed capabilities will be included, the effect of the assignment inverted. If the empty string is assigned to this option, the ambient capability set is reset to the empty capability set, and all prior settings have no effect. If set to ~ (without any further argument), the ambient capability set is reset to the full set of available capabilities, also undoing any previous settings. Note that adding capabilities to the ambient capability set adds them to the process's inherited capability set. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
432
|
+
readonly AmbientCapabilities?: string | readonly string[];
|
|
433
|
+
/** Takes a profile name as argument. The process executed by the unit will switch to this profile when started. Profiles must already be loaded in the kernel, or the unit will fail. If prefixed by -, all errors will be ignored. This setting has no effect if AppArmor is not enabled. This setting does not affect commands prefixed with +. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
434
|
+
readonly AppArmorProfile?: string;
|
|
435
|
+
/** Accepts a list of BPF attach points to allow or any to allow everything. Defaults to none. The accepted values are: This will set the delegate_attachs bpffs mount option. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
436
|
+
readonly BPFDelegateAttachments?: string | readonly string[];
|
|
437
|
+
/** Accepts a list of BPF commands to allow or any to allow everything. Defaults to none. The accepted values are: This will set the delegate_cmds bpffs mount option. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
438
|
+
readonly BPFDelegateCommands?: string | readonly string[];
|
|
439
|
+
/** Accepts a list of BPF maps to allow or any to allow everything. Defaults to none. The accepted values are: This will set the delegate_maps bpffs mount option. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
440
|
+
readonly BPFDelegateMaps?: string | readonly string[];
|
|
441
|
+
/** Accepts a list of BPF programs to allow or any to allow everything. Defaults to none. The accepted values are: This will set the delegate_progs bpffs mount option. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
442
|
+
readonly BPFDelegatePrograms?: string | readonly string[];
|
|
443
|
+
/** Allows attaching custom BPF programs to the cgroup of a unit. (This generalizes the functionality exposed via IPEgressFilterPath= and IPIngressFilterPath= for other hooks.) Cgroup-bpf hooks in the form of BPF programs loaded to the BPF filesystem are attached with cgroup-bpf attach flags determined by the unit. For details about attachment types and flags see bpf.h. Also refer to the general BPF documentation. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
444
|
+
readonly BPFProgram?: string | readonly string[];
|
|
445
|
+
/** If true, sockets from systemd-journald.socket8 will be bind mounted into the mount namespace. This is particularly useful when a different instance of /run/ is employed, to make sure processes running in the namespace can still make use of sd-journal3. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
446
|
+
readonly BindLogSockets?: boolean;
|
|
447
|
+
/** Takes the name of a network interface. This option causes every socket created by processes of this unit to be bound to the specified network interface. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
448
|
+
readonly BindNetworkInterface?: string;
|
|
449
|
+
/** Configures unit-specific bind mounts. A bind mount makes a particular file or directory available at an additional place in the unit's view of the file system. Any bind mounts created with this option are specific to the unit, and are not visible in the host's mount table. This option expects a whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of source path, destination path and option string, where the latter two are optional. If only a source path is specified the source and destination is taken to be the same. The option string may be either rbind or norbind for configuring a recursive or non-recursive bind mount. If the destination path is omitted, the option string must be omitted too. Each bind mount definition may be prefixed with -, in which case it will be ignored when its source path does not exist or is not accessible. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
450
|
+
readonly BindPaths?: string | readonly string[];
|
|
451
|
+
/** Configures unit-specific bind mounts. A bind mount makes a particular file or directory available at an additional place in the unit's view of the file system. Any bind mounts created with this option are specific to the unit, and are not visible in the host's mount table. This option expects a whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of source path, destination path and option string, where the latter two are optional. If only a source path is specified the source and destination is taken to be the same. The option string may be either rbind or norbind for configuring a recursive or non-recursive bind mount. If the destination path is omitted, the option string must be omitted too. Each bind mount definition may be prefixed with -, in which case it will be ignored when its source path does not exist or is not accessible. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
452
|
+
readonly BindReadOnlyPaths?: string | readonly string[];
|
|
453
|
+
/** Takes a D-Bus destination name that this service shall use. This option is mandatory for services where Type= is set to dbus. It is recommended to always set this property if known to make it easy to map the service name to the D-Bus destination. In particular, systemctl service-log-level/service-log-target verbs make use of this. Source: systemd v260.1, `systemd.service(5)`. */
|
|
454
|
+
readonly BusName?: string;
|
|
455
|
+
/** Controls the CPU affinity of the executed processes. Takes a list of CPU indices or ranges separated by either whitespace or commas. Alternatively, takes a special "numa" value in which case systemd automatically derives allowed CPU range based on the value of NUMAMask= option. 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. See sched_setaffinity(2) for details. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
456
|
+
readonly CPUAffinity?: string | readonly string[];
|
|
457
|
+
/** This setting controls the cpu controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
458
|
+
readonly CPUQuota?: number | string;
|
|
459
|
+
/** This setting controls the cpu controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
460
|
+
readonly CPUQuotaPeriodSec?: number | string;
|
|
461
|
+
/** Sets the CPU scheduling policy for executed processes. Takes one of other, batch, idle, fifo, rr or ext. See sched_setscheduler(2) for details. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
462
|
+
readonly CPUSchedulingPolicy?: CPUSchedulingPolicyDirectiveValue;
|
|
463
|
+
/** Sets the CPU scheduling priority for executed processes. The available priority range depends on the selected CPU scheduling policy (see above). For real-time scheduling policies an integer between 1 (lowest priority) and 99 (highest priority) can be used. In case of CPU resource contention, smaller values mean less CPU time is made available to the service, larger values mean more. See sched_setscheduler(2) for details. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
464
|
+
readonly CPUSchedulingPriority?: number;
|
|
465
|
+
/** If true, elevated CPU scheduling priorities and policies will be reset when the executed processes call fork2, and can hence not leak into child processes. See sched_setscheduler(2) for details. Defaults to false. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
466
|
+
readonly CPUSchedulingResetOnFork?: boolean;
|
|
467
|
+
/** These settings control the cpu controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
468
|
+
readonly CPUWeight?: number | string;
|
|
469
|
+
/** Relative cache directories to create for the service under `/var/cache`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
470
|
+
readonly CacheDirectory?: string;
|
|
471
|
+
/** Enables project-quota accounting for directories created by `CacheDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
472
|
+
readonly CacheDirectoryAccounting?: boolean;
|
|
473
|
+
/** File mode to apply to directories created by `CacheDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
474
|
+
readonly CacheDirectoryMode?: string;
|
|
475
|
+
/** Storage quota for directories created by `CacheDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
476
|
+
readonly CacheDirectoryQuota?: number | string;
|
|
477
|
+
/** Controls which capabilities to include in the capability bounding set for the executed process. See capabilities(7) for details. Takes a whitespace-separated list of capability names, e.g. CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE. 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. If this option is not used, the capability bounding set is not modified on process execution, hence no limits on the capabilities of the process are enforced. This option may appear more than once, in which case the bounding sets are merged by OR, or by AND if the lines are prefixed with ~ (see below). If the empty string is assigned to this option, the bounding set is reset to the empty capability set, and all prior settings have no effect. If set to ~ (without any further argument), the bounding set is reset to the full set of available capabilities, also undoing any previous settings. This does not affect commands prefixed with +. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
478
|
+
readonly CapabilityBoundingSet?: string | readonly string[];
|
|
479
|
+
/** Relative configuration directories to create for the service under `/etc`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
480
|
+
readonly ConfigurationDirectory?: string;
|
|
481
|
+
/** File mode to apply to directories created by `ConfigurationDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
482
|
+
readonly ConfigurationDirectoryMode?: string;
|
|
483
|
+
/** Controls which types of memory mappings will be saved if the process dumps core (using the /proc/pid/coredump_filter file). Takes a whitespace-separated combination of mapping type names or numbers (with the default base 16). Mapping type names are private-anonymous, shared-anonymous, private-file-backed, shared-file-backed, elf-headers, private-huge, shared-huge, private-dax, shared-dax, and the special values all (all types) and default (the kernel default of private-anonymous shared-anonymous elf-headers private-huge). See core(5) for the meaning of the mapping types. When specified multiple times, all specified masks are ORed. When not set, or if the empty value is assigned, the inherited value is not changed. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
484
|
+
readonly CoredumpFilter?: string | readonly string[];
|
|
485
|
+
/** This setting is used to enable coredump forwarding for containers that belong to this unit's cgroup. Units with CoredumpReceive=yes must also be configured with Delegate=yes. Defaults to false. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
486
|
+
readonly CoredumpReceive?: boolean;
|
|
487
|
+
/** Turns on delegation of further resource control partitioning to processes of the unit. Units where this is enabled may create and manage their own private subhierarchy of control groups below the control group of the unit itself. For unprivileged services (i.e. those using the User= setting) the unit's control group will be made accessible to the relevant user. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
488
|
+
readonly Delegate?: boolean | string | readonly string[];
|
|
489
|
+
/** Delegates ownership of the given namespace types to the user namespace of the processes of this unit. For details about Linux namespaces, see namespaces(7). Either takes a boolean argument, or a space-separated list of namespace type identifiers. If false (the default), the unit's processes' user namespace will not have ownership over any namespaces created during setup of the unit's sandboxed environment. If true, ownership of all namespace types (except for user namespaces, where the concept doesn't apply) created during setup of the unit's sandboxed environment is delegated to the unit's processes' user namespace. Otherwise, a space-separated list of namespace type identifiers must be specified, consisting of any combination of: cgroup, ipc, net, mnt, pid, and uts. All namespaces of the listed types will be owned by the unit's processes' user namespace if they are created during setup of the unit's sandboxed environment (allow-listing). By prepending the list with a single tilde character (~) the effect may be inverted: all namespaces of types not listed and created during setup of the unit's sandboxed environment will be owned by the unit's processes' user namespace (deny-listing). If the empty string is assigned, the default namespace ownership is applied, which is equivalent to false. This option may appear more than once, in which case the namespace types are merged by OR, or by AND if the lines are prefixed with ~ (see examples below). Internally, this setting controls the order in which namespaces are unshared by systemd. Namespace types that should be owned by the unit's processes' user namespace will be unshared after unsharing the user namespace. Internally, this setting controls the order in which namespaces are unshared. Delegated namespaces will be unshared after the user namespace is unshared. Other namespaces will be unshared before the user namespace is unshared. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
490
|
+
readonly DelegateNamespaces?: boolean | string | readonly string[];
|
|
491
|
+
/** Place unit processes in the specified subgroup of the unit's control group. Takes a valid control group name (not a path!) as parameter, or an empty string to turn this feature off. Defaults to off. The control group name must be usable as filename and avoid conflicts with the kernel's control group attribute files (i.e. cgroup.procs is not an acceptable name, since the kernel exposes a native control group attribute file by that name). This option has no effect unless control group delegation is turned on via Delegate=, see above. Note that this setting only applies to "main" processes of a unit, i.e. for services to ExecStart=, but not for ExecReload= and similar. If delegation is enabled, the latter are always placed inside a subgroup named .control. The specified subgroup is automatically created (and potentially ownership is passed to the unit's configured user/group) when a process is started in it. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
492
|
+
readonly DelegateSubgroup?: string;
|
|
493
|
+
/** Control access to specific device nodes by the executed processes. Takes two space-separated strings: a device node specifier followed by a combination of r, w, m to control reading, writing, or creation of the specific device nodes by the unit (mknod), respectively. This functionality is implemented using eBPF filtering. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
494
|
+
readonly DeviceAllow?: string | readonly string[];
|
|
495
|
+
/** Control the policy for allowing device access:. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
496
|
+
readonly DevicePolicy?: DevicePolicyDirectiveValue;
|
|
497
|
+
/** Disables controllers from being enabled for a unit's children. If a controller listed is already in use in its subtree, the controller will be removed from the subtree. This can be used to avoid configuration in child units from being able to implicitly or explicitly enable a controller. Defaults to empty. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
498
|
+
readonly DisableControllers?: string | readonly string[];
|
|
499
|
+
/** Takes a boolean parameter. If set, a UNIX user and group pair is allocated dynamically when the unit is started, and released as soon as it is stopped. The user and group will not be added to /etc/passwd or /etc/group, but are managed transiently during runtime. The nss-systemd8 glibc NSS module provides integration of these dynamic users/groups into the system's user and group databases. The user and group name to use may be configured via User= and Group= (see above). If these options are not used and dynamic user/group allocation is enabled for a unit, the name of the dynamic user/group is implicitly derived from the unit name. If the unit name without the type suffix qualifies as valid user name it is used directly, otherwise a name incorporating a hash of it is used. If a statically allocated user or group of the configured name already exists, it is used and no dynamic user/group is allocated. Note that if User= is specified and the static group with the name exists, then it is required that the static user with the name already exists. Similarly, if Group= is specified and the static user with the name exists, then it is required that the static group with the name already exists. Dynamic users/groups are allocated from the UID/GID range 61184…65519. It is recommended to avoid this range for regular system or login users. At any point in time each UID/GID from this range is only assigned to zero or one dynamically allocated users/groups in use. However, UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus gain access to these files or directories. If DynamicUser= is enabled, RemoveIPC= is implied (and cannot be turned off). This ensures that the lifetime of IPC objects and temporary files created by the executed processes is bound to the runtime of the service, and hence the lifetime of the dynamic user/group. Since /tmp/ and /var/tmp/ are usually the only world-writable directories on a system, unless PrivateTmp= is manually set to true, disconnected would be implied. This ensures that a unit making use of dynamic user/group allocation cannot leave files around after unit termination. Furthermore NoNewPrivileges= and RestrictSUIDSGID= are implicitly enabled (and cannot be disabled), to ensure that processes invoked cannot take benefit or create SUID/SGID files or directories. Moreover, ProtectSystem=strict and ProtectHome=read-only are implied, thus prohibiting the service to write to arbitrary file system locations. In order to allow the service to write to certain directories, they have to be allow-listed using ReadWritePaths=, but care must be taken so that UID/GID recycling does not create security issues involving files created by the service. Use RuntimeDirectory= (see below) in order to assign a writable runtime directory to a service, owned by the dynamic user/group and removed automatically when the unit is terminated. Use StateDirectory=, CacheDirectory= and LogsDirectory= in order to assign a set of writable directories for specific purposes to the service in a way that they are protected from vulnerabilities due to UID reuse (see below). If this option is enabled, care should be taken that the unit's processes do not get access to directories outside of these explicitly configured and managed ones. Specifically, do not use BindPaths= and be careful with AF_UNIX file descriptor passing for directory file descriptors, as this would permit processes to create files or directories owned by the dynamic user/group that are not subject to the lifecycle and access guarantees of the service. Note that this option is currently incompatible with D-Bus policies, thus a service using this option may currently not allocate a D-Bus service name (note that this does not affect calling into other D-Bus services). Defaults to off. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
500
|
+
readonly DynamicUser?: boolean;
|
|
501
|
+
/** Sets environment variables for executed processes. Each line is unquoted using the rules described in "Quoting" section in systemd.syntax7 and becomes a list of variable assignments. If you need to assign a value containing spaces or the equals sign to a variable, put quotes around the whole assignment. Variable expansion is not performed inside the strings and the $ character has no special meaning. Specifier expansion is performed, see the "Specifiers" section in systemd.unit5. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
502
|
+
readonly Environment?: string | readonly string[];
|
|
503
|
+
/** Similar to Environment=, but reads the environment variables from a text file. The text file should contain newline-separated variable assignments. Empty lines, lines without an = separator, or lines starting with ; or # will be ignored, which may be used for commenting. The file must be encoded with UTF-8. Valid characters are unicode scalar values other than unicode noncharacters, U+0000 NUL, and U+FEFF unicode byte order mark. Control codes other than NUL are allowed. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
504
|
+
readonly EnvironmentFile?: string | readonly string[];
|
|
505
|
+
/** Optional commands that are executed before the commands in ExecStartPre=. Syntax is the same as for ExecStart=. Multiple command lines are allowed, regardless of the service type (i.e. Type=), and the commands are executed one after the other, serially. Source: systemd v260.1, `systemd.service(5)`. */
|
|
506
|
+
readonly ExecCondition?: ExecDirective;
|
|
507
|
+
/** Paths from which execution is explicitly allowed when `NoExecPaths=` is used. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
508
|
+
readonly ExecPaths?: string | readonly string[];
|
|
509
|
+
/** Commands to execute to trigger a configuration reload in the service. This setting may take multiple command lines, following the same scheme as described for ExecStart= above. Use of this setting is optional. Specifier and environment variable substitution is supported here following the same scheme as for ExecStart=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
510
|
+
readonly ExecReload?: ExecDirective;
|
|
511
|
+
/** Commands to execute after a successful reload operation. Syntax for this setting is exactly the same as ExecReload=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
512
|
+
readonly ExecReloadPost?: ExecDirective;
|
|
513
|
+
/** Takes a colon separated list of absolute paths relative to which the executable used by the Exec*= (e.g. ExecStart=, ExecStop=, etc.) properties can be found. Overrides $PATH if $PATH is not supplied by the user through Environment=, EnvironmentFile= or PassEnvironment=. Assigning an empty string removes previous assignments and setting ExecSearchPath= to a value multiple times will append to the previous setting. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
514
|
+
readonly ExecSearchPath?: string | readonly string[];
|
|
515
|
+
/** Commands that are executed when this service is started. Source: systemd v260.1, `systemd.service(5)`. */
|
|
516
|
+
readonly ExecStart?: ExecDirective;
|
|
517
|
+
/** Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=. Multiple command lines are allowed, regardless of the service type (i.e. Type=), and the commands are executed one after the other, serially. Source: systemd v260.1, `systemd.service(5)`. */
|
|
518
|
+
readonly ExecStartPost?: ExecDirective;
|
|
519
|
+
/** Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=. Multiple command lines are allowed, regardless of the service type (i.e. Type=), and the commands are executed one after the other, serially. Source: systemd v260.1, `systemd.service(5)`. */
|
|
520
|
+
readonly ExecStartPre?: ExecDirective;
|
|
521
|
+
/** Commands to execute to stop the service started via ExecStart=. This argument takes multiple command lines, following the same scheme as described for ExecStart= above. Use of this setting is optional. After the commands configured in this option are run, it is implied that the service is stopped, and any processes remaining for it are terminated according to the KillMode= setting (see systemd.kill5). If this option is not specified, the process is terminated by sending the signal specified in KillSignal= or RestartKillSignal= when service stop is requested. Specifier and environment variable substitution is supported (including $MAINPID, see above). Source: systemd v260.1, `systemd.service(5)`. */
|
|
522
|
+
readonly ExecStop?: ExecDirective;
|
|
523
|
+
/** Additional commands that are executed after the service is stopped. This includes cases where the commands configured in ExecStop= were used, where the service does not have any ExecStop= defined, or where the service exited unexpectedly. This argument takes multiple command lines, following the same scheme as described for ExecStart=. Use of these settings is optional. Specifier and environment variable substitution is supported. Note that – unlike ExecStop= – commands specified with this setting are invoked when a service failed to start up correctly and is shut down again. Source: systemd v260.1, `systemd.service(5)`. */
|
|
524
|
+
readonly ExecStopPost?: ExecDirective;
|
|
525
|
+
/** Specifies when the manager should consider the service to be finished. One of main or cgroup:. Source: systemd v260.1, `systemd.service(5)`. */
|
|
526
|
+
readonly ExitType?: ServiceExitTypeDirectiveValue;
|
|
527
|
+
/** This setting is similar to BindReadOnlyPaths= in that it mounts a file system hierarchy from a directory, but instead of providing a destination path, an overlay will be set up. This option expects a whitespace separated list of source directories. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
528
|
+
readonly ExtensionDirectories?: string | readonly string[];
|
|
529
|
+
/** Takes an image policy string as per systemd.image-policy7 to use when mounting the disk images (DDI) specified in RootImage=, MountImage=, ExtensionImage=, respectively. If not specified the following policy string is the default for RootImagePolicy= and MountImagePolicy:. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
530
|
+
readonly ExtensionImagePolicy?: string;
|
|
531
|
+
/** This setting is similar to MountImages= in that it mounts a file system hierarchy from a block device node or loopback file, but instead of providing a destination path, an overlay will be set up. This option expects a whitespace separated list of mount definitions. Each definition consists of a source path, optionally followed by a colon and a list of mount options. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
532
|
+
readonly ExtensionImages?: string | readonly string[];
|
|
533
|
+
/** Configure how many file descriptors may be stored in the service manager for the service using sd_pid_notify_with_fds3's FDSTORE=1 messages. This is useful for implementing services that can restart after an explicit request or a crash without losing state. Any open sockets and other file descriptors which should not be closed during the restart may be stored this way. Application state can either be serialized to a file in RuntimeDirectory=, or stored in a memfd_create2 memory file descriptor. Defaults to 0, i.e. no file descriptors may be stored in the service manager. All file descriptors passed to the service manager from a specific service are passed back to the service's main process on the next service restart (see sd_listen_fds3 for details about the precise protocol used and the order in which the file descriptors are passed). Any file descriptors passed to the service manager are automatically closed when POLLHUP or POLLERR is seen on them, or when the service is fully stopped and no job is queued or being executed for it (the latter can be tweaked with FileDescriptorStorePreserve=, see below). If this option is used, NotifyAccess= (see above) should be set to open access to the notification socket provided by systemd. If NotifyAccess= is not set, it will be implicitly set to main. Source: systemd v260.1, `systemd.service(5)`. */
|
|
534
|
+
readonly FileDescriptorStoreMax?: number;
|
|
535
|
+
/** Takes one of no, yes, restart and controls when to release the service's file descriptor store (i.e. when to close the contained file descriptors, if any). If set to no the file descriptor store is automatically released when the service is stopped; if restart (the default) it is kept around as long as the unit is neither inactive nor failed, or a job is queued for the service, or the service is expected to be restarted. If yes the file descriptor store is kept around until the unit is removed from memory (i.e. is not referenced anymore and inactive). The latter is useful to keep entries in the file descriptor store pinned until the service manager exits. Source: systemd v260.1, `systemd.service(5)`. */
|
|
536
|
+
readonly FileDescriptorStorePreserve?: FileDescriptorStorePreserveDirectiveValue;
|
|
537
|
+
/** Specifies which signal to send to remaining processes after a timeout if SendSIGKILL= is enabled. The signal configured here should be one that is not typically caught and processed by services (SIGTERM is not suitable). Developers can find it useful to use this to generate a coredump to troubleshoot why a service did not terminate upon receiving the initial SIGTERM signal. This can be achieved by configuring LimitCORE= and setting FinalKillSignal= to either SIGQUIT or SIGABRT. Defaults to SIGKILL. Source: systemd v260.1, `systemd.kill(5)`. */
|
|
538
|
+
readonly FinalKillSignal?: NodeJS.Signals | number;
|
|
539
|
+
/** Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or a numeric ID as argument. For system services (services run by the system service manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of systemd --user), the default is root, but this directive may be used to specify a different identity. For user services of any other user, switching user identity is not permitted, hence the only valid setting is the same user the user's service manager is running as. If no group is set, the default group of the user is used. This setting does not affect commands whose command line is prefixed with +. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
540
|
+
readonly Group?: string;
|
|
541
|
+
/** Takes a boolean value that specifies whether systemd should try to guess the main PID of a service if it cannot be determined reliably. This option is ignored unless Type=forking is set and PIDFile= is unset because for the other types or with an explicitly configured PID file, the main PID is always known. The guessing algorithm might come to incorrect conclusions if a daemon consists of more than one process. If the main PID cannot be determined, failure detection and automatic restarting of a service will not work reliably. Defaults to yes. Source: systemd v260.1, `systemd.service(5)`. */
|
|
542
|
+
readonly GuessMainPID?: boolean;
|
|
543
|
+
/** This setting controls the io controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
544
|
+
readonly IOAccounting?: boolean;
|
|
545
|
+
/** This setting controls the io controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
546
|
+
readonly IODeviceLatencyTargetSec?: number | string;
|
|
547
|
+
/** This setting controls the io controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
548
|
+
readonly IODeviceWeight?: number | string;
|
|
549
|
+
/** These settings control the io controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
550
|
+
readonly IOReadBandwidthMax?: string | readonly string[];
|
|
551
|
+
/** These settings control the io controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
552
|
+
readonly IOReadIOPSMax?: string | readonly string[];
|
|
553
|
+
/** Sets the I/O scheduling class for executed processes. Takes one of the strings realtime, best-effort or idle. The kernel's default scheduling class is best-effort at a priority of 4. If the empty string is assigned to this option, all prior assignments to both IOSchedulingClass= and IOSchedulingPriority= have no effect. See ioprio_set2 for details. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
554
|
+
readonly IOSchedulingClass?: IOSchedulingClassDirectiveValue;
|
|
555
|
+
/** Sets the I/O scheduling priority for executed processes. Takes an integer between 0 (highest priority) and 7 (lowest priority). In case of I/O contention, smaller values mean more I/O bandwidth is made available to the unit's processes, larger values mean less bandwidth. The available priorities depend on the selected I/O scheduling class (see above). If the empty string is assigned to this option, all prior assignments to both IOSchedulingClass= and IOSchedulingPriority= have no effect. For the kernel's default scheduling class (best-effort) this defaults to 4. See ioprio_set2 for details. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
556
|
+
readonly IOSchedulingPriority?: number;
|
|
557
|
+
/** These settings control the io controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
558
|
+
readonly IOWeight?: number | string;
|
|
559
|
+
/** See systemd.service(5) for IOWriteBandwidthMax=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
560
|
+
readonly IOWriteBandwidthMax?: string | readonly string[];
|
|
561
|
+
/** See systemd.service(5) for IOWriteIOPSMax=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
562
|
+
readonly IOWriteIOPSMax?: string | readonly string[];
|
|
563
|
+
/** If true, turns on IPv4 and IPv6 network traffic accounting for packets sent or received by the unit. When this option is turned on, all IPv4 and IPv6 sockets created by any process of the unit are accounted for. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
564
|
+
readonly IPAccounting?: boolean;
|
|
565
|
+
/** Turn on network traffic filtering for IP packets sent and received over AF_INET and AF_INET6 sockets. Both directives take a space separated list of IPv4 or IPv6 addresses, each optionally suffixed with an address prefix length in bits after a / character. If the suffix is omitted, the address is considered a host address, i.e. the filter covers the whole address (32 bits for IPv4, 128 bits for IPv6). Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
566
|
+
readonly IPAddressAllow?: string | readonly string[];
|
|
567
|
+
/** See systemd.service(5) for IPAddressDeny=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
568
|
+
readonly IPAddressDeny?: string | readonly string[];
|
|
569
|
+
/** See systemd.service(5) for IPEgressFilterPath=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
570
|
+
readonly IPEgressFilterPath?: string | readonly string[];
|
|
571
|
+
/** Add custom network traffic filters implemented as BPF programs, applying to all IP packets sent and received over AF_INET and AF_INET6 sockets. Takes an absolute path to a pinned BPF program in the BPF virtual filesystem (/sys/fs/bpf/). Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
572
|
+
readonly IPIngressFilterPath?: string | readonly string[];
|
|
573
|
+
/** Takes an absolute file system path referring to a Linux IPC namespace pseudo-file (i.e. a file like /proc/$PID/ns/ipc or a bind mount or symlink to one). When set the invoked processes are added to the network namespace referenced by that path. The path has to point to a valid namespace file at the moment the processes are forked off. If this option is used PrivateIPC= has no effect. If this option is used together with JoinsNamespaceOf= then it only has an effect if this unit is started before any of the listed units that have PrivateIPC= or IPCNamespacePath= configured, as otherwise the network namespace of those units is reused. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
574
|
+
readonly IPCNamespacePath?: string;
|
|
575
|
+
/** If true, SIGPIPE is ignored in the executed process. Defaults to true since SIGPIPE is generally only useful in shell pipelines. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
576
|
+
readonly IgnoreSIGPIPE?: boolean;
|
|
577
|
+
/** Pass one or more credentials to the unit. Takes a credential name for which we will attempt to find a credential that the service manager itself received under the specified name — which may be used to propagate credentials from an invoking environment (e.g. a container manager that invoked the service manager) into a service. If the credential name is a glob, all credentials matching the glob are passed to the unit. Matching credentials are searched for in the system credentials, the encrypted system credentials, and under /etc/credstore/, /run/credstore/, /usr/lib/credstore/, /run/credstore.encrypted/, /etc/credstore.encrypted/, and /usr/lib/credstore.encrypted/ in that order. When multiple credentials of the same name are found, the first one found is used. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
578
|
+
readonly ImportCredential?: string | readonly string[];
|
|
579
|
+
/** Paths that should be hidden entirely from the service. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
580
|
+
readonly InaccessiblePaths?: string | readonly string[];
|
|
581
|
+
/** Controls how the kernel session keyring is set up for the service (see session-keyring7 for details on the session keyring). Takes one of inherit, private, shared. If set to inherit no special keyring setup is done, and the kernel's default behaviour is applied. If private is used a new session keyring is allocated when a service process is invoked, and it is not linked up with any user keyring. This is the recommended setting for system services, as this ensures that multiple services running under the same system user ID (in particular the root user) do not share their key material among each other. If shared is used a new session keyring is allocated as for private, but the user keyring of the user configured with User= is linked into it, so that keys assigned to the user may be requested by the unit's processes. In this mode multiple units running processes under the same user ID may share key material. Unless inherit is selected the unique invocation ID for the unit (see below) is added as a protected key by the name invocation_id to the newly created session keyring. Defaults to private for services of the system service manager and to inherit for non-service units and for services of the user service manager. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
582
|
+
readonly KeyringMode?: KeyringModeDirectiveValue;
|
|
583
|
+
/** Specifies how processes of this unit shall be killed. One of control-group, mixed, process, none. Source: systemd v260.1, `systemd.kill(5)`. */
|
|
584
|
+
readonly KillMode?: "control-group" | "mixed" | "process" | "none";
|
|
585
|
+
/** Specifies which signal to use when stopping a service. This controls the signal that is sent as first step of shutting down a unit (see above), and is usually followed by SIGKILL (see above and below). For a list of valid signals, see signal(7). Defaults to SIGTERM. Source: systemd v260.1, `systemd.kill(5)`. */
|
|
586
|
+
readonly KillSignal?: NodeJS.Signals | number;
|
|
587
|
+
/** Maximum address-space size for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
588
|
+
readonly LimitAS?: ProcessResourceLimitDirectiveValue;
|
|
589
|
+
/** Maximum core-file size for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
590
|
+
readonly LimitCORE?: ProcessResourceLimitDirectiveValue;
|
|
591
|
+
/** Maximum CPU time for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
592
|
+
readonly LimitCPU?: ProcessResourceLimitDirectiveValue;
|
|
593
|
+
/** Maximum data-segment size for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
594
|
+
readonly LimitDATA?: ProcessResourceLimitDirectiveValue;
|
|
595
|
+
/** Maximum created-file size for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
596
|
+
readonly LimitFSIZE?: ProcessResourceLimitDirectiveValue;
|
|
597
|
+
/** Maximum number of file locks for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
598
|
+
readonly LimitLOCKS?: ProcessResourceLimitDirectiveValue;
|
|
599
|
+
/** Maximum locked-in-memory size for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
600
|
+
readonly LimitMEMLOCK?: ProcessResourceLimitDirectiveValue;
|
|
601
|
+
/** Maximum POSIX message-queue size for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
602
|
+
readonly LimitMSGQUEUE?: ProcessResourceLimitDirectiveValue;
|
|
603
|
+
/** Maximum nice-priority adjustment for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
604
|
+
readonly LimitNICE?: ProcessResourceLimitDirectiveValue;
|
|
605
|
+
/** Maximum number of open file descriptors for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
606
|
+
readonly LimitNOFILE?: ProcessResourceLimitDirectiveValue;
|
|
607
|
+
/** Maximum number of processes or threads for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
608
|
+
readonly LimitNPROC?: ProcessResourceLimitDirectiveValue;
|
|
609
|
+
/** Maximum resident-set size for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
610
|
+
readonly LimitRSS?: ProcessResourceLimitDirectiveValue;
|
|
611
|
+
/** Maximum real-time scheduling priority for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
612
|
+
readonly LimitRTPRIO?: ProcessResourceLimitDirectiveValue;
|
|
613
|
+
/** Maximum real-time CPU time for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
614
|
+
readonly LimitRTTIME?: ProcessResourceLimitDirectiveValue;
|
|
615
|
+
/** Maximum number of queued signals for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
616
|
+
readonly LimitSIGPENDING?: ProcessResourceLimitDirectiveValue;
|
|
617
|
+
/** Maximum stack size for processes started by the unit. Accepts the usual `soft:hard` syntax, `infinity`, and unit suffixes where systemd allows them. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
618
|
+
readonly LimitSTACK?: ProcessResourceLimitDirectiveValue;
|
|
619
|
+
/** Pass a credential to the unit. Credentials are limited-size binary or textual objects that may be passed to unit processes. They are primarily intended for passing cryptographic keys (both public and private) or certificates, user account information or identity information from host to services, but can be freely used to pass any kind of limited-size information to a service. The data is accessible from the unit's processes via the file system, at a read-only location that (if possible and permitted) is backed by non-swappable memory. The data is only accessible to the user associated with the unit, via the User=/DynamicUser= settings (as well as the superuser). When available, the location of credentials is exported as the $CREDENTIALS_DIRECTORY environment variable to the unit's processes. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
620
|
+
readonly LoadCredential?: string | readonly string[];
|
|
621
|
+
/** Pass a credential to the unit. Credentials are limited-size binary or textual objects that may be passed to unit processes. They are primarily intended for passing cryptographic keys (both public and private) or certificates, user account information or identity information from host to services, but can be freely used to pass any kind of limited-size information to a service. The data is accessible from the unit's processes via the file system, at a read-only location that (if possible and permitted) is backed by non-swappable memory. The data is only accessible to the user associated with the unit, via the User=/DynamicUser= settings (as well as the superuser). When available, the location of credentials is exported as the $CREDENTIALS_DIRECTORY environment variable to the unit's processes. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
622
|
+
readonly LoadCredentialEncrypted?: string | readonly string[];
|
|
623
|
+
/** If set, locks down the personality2 system call so that the kernel execution domain may not be changed from the default or the personality selected with Personality= directive. This may be useful to improve security, because odd personality emulations may be poorly tested and source of vulnerabilities. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
624
|
+
readonly LockPersonality?: boolean;
|
|
625
|
+
/** Configures additional log metadata fields to include in all log records generated by processes associated with this unit, including systemd. This setting takes one or more journal field assignments in the format FIELD=VALUE separated by whitespace. See systemd.journal-fields7 for details on the journal field concept. Even though the underlying journal implementation permits binary field values, this setting accepts only valid UTF-8 values. To include space characters in a journal field value, enclose the assignment in double quotes ("). The usual specifiers are expanded in all assignments (see below). Note that this setting is not only useful for attaching additional metadata to log records of a unit, but given that all fields and values are indexed may also be used to implement cross-unit log record matching. Assign an empty string to reset the list. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
626
|
+
readonly LogExtraFields?: string | readonly string[];
|
|
627
|
+
/** Define an extended regular expression to filter log messages based on the MESSAGE= field of the structured message. If the first character of the pattern is ~, log entries matching the pattern should be discarded. This option takes a single pattern as an argument but can be used multiple times to create a list of allowed and denied patterns. If the empty string is assigned, the filter is reset, and all prior assignments will have no effect. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
628
|
+
readonly LogFilterPatterns?: string | readonly string[];
|
|
629
|
+
/** Sets the maximum log level for log messages generated by this unit. Takes a syslog log level, one of emerg (lowest log level, only highest priority messages), alert, crit, err, warning, notice, info, debug (highest log level, also lowest priority messages). See syslog3 for details. By default, the maximum log level is not overridden. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
630
|
+
readonly LogLevelMax?: SyslogLevelDirectiveValue;
|
|
631
|
+
/** Run the unit's processes in the specified journal namespace. Expects a short user-defined string identifying the namespace. If not used the processes of the service are run in the default journal namespace, i.e. their log stream is collected and processed by systemd-journald.service. If this option is used any log data generated by processes of this unit (regardless of whether via the syslog(), journal native logging or stdout/stderr logging) is collected and processed by an instance of the systemd-journald@.service template unit, which manages the specified namespace. The log data is stored in a data store independent from the default log namespace's data store. See systemd-journald.service8 for details about journal namespaces. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
632
|
+
readonly LogNamespace?: string;
|
|
633
|
+
/** Configures the rate limiting that is applied to log messages generated by this unit. If, in the time interval defined by LogRateLimitIntervalSec=, more messages than specified in LogRateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over. A message about the number of dropped messages is generated. The time specification for LogRateLimitIntervalSec= may be specified in the following units: "s", "min", "h", "ms", "us". See systemd.time(7) for details. The default settings are set by RateLimitIntervalSec= and RateLimitBurst= configured in journald.conf5. Note that this only applies to log messages that are processed by the logging subsystem, i.e. by systemd-journald.service8. This means that if you connect a service's stderr directly to a file via StandardOutput=file:… or a similar setting, the rate limiting will not be applied to messages written that way (but it will be enforced for messages generated via syslog3 and similar functions). Source: systemd v260.1, `systemd.exec(5)`. */
|
|
634
|
+
readonly LogRateLimitBurst?: number;
|
|
635
|
+
/** Configures the rate limiting that is applied to log messages generated by this unit. If, in the time interval defined by LogRateLimitIntervalSec=, more messages than specified in LogRateLimitBurst= are logged by a service, all further messages within the interval are dropped until the interval is over. A message about the number of dropped messages is generated. The time specification for LogRateLimitIntervalSec= may be specified in the following units: "s", "min", "h", "ms", "us". See systemd.time(7) for details. The default settings are set by RateLimitIntervalSec= and RateLimitBurst= configured in journald.conf5. Note that this only applies to log messages that are processed by the logging subsystem, i.e. by systemd-journald.service8. This means that if you connect a service's stderr directly to a file via StandardOutput=file:… or a similar setting, the rate limiting will not be applied to messages written that way (but it will be enforced for messages generated via syslog3 and similar functions). Source: systemd v260.1, `systemd.exec(5)`. */
|
|
636
|
+
readonly LogRateLimitIntervalSec?: number | string;
|
|
637
|
+
/** Relative log directories to create for the service under `/var/log`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
638
|
+
readonly LogsDirectory?: string;
|
|
639
|
+
/** Enables project-quota accounting for directories created by `LogsDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
640
|
+
readonly LogsDirectoryAccounting?: boolean;
|
|
641
|
+
/** File mode to apply to directories created by `LogsDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
642
|
+
readonly LogsDirectoryMode?: string;
|
|
643
|
+
/** Storage quota for directories created by `LogsDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
644
|
+
readonly LogsDirectoryQuota?: number | string;
|
|
645
|
+
/** See systemd.service(5) for ManagedOOMMemoryPressure=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
646
|
+
readonly ManagedOOMMemoryPressure?: ManagedOOMDirectiveValue;
|
|
647
|
+
/** Overrides the default memory pressure duration set by oomd.conf5 for the cgroup of this unit. The specified value supports a time unit such as ms or μs, see systemd.time(7) for details on the permitted syntax. Must be set to either empty or a value of at least 1s. Defaults to empty, which means to use the default set by oomd.conf5. This property is ignored unless ManagedOOMMemoryPressure=kill. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
648
|
+
readonly ManagedOOMMemoryPressureDurationSec?: number | string;
|
|
649
|
+
/** Overrides the default memory pressure limit set by oomd.conf5 for the cgroup of this unit. Takes a percentage value between 0% and 100%, inclusive. Defaults to 0%, which means to use the default set by oomd.conf5. This property is ignored unless ManagedOOMMemoryPressure=kill. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
650
|
+
readonly ManagedOOMMemoryPressureLimit?: string;
|
|
651
|
+
/** Allows deprioritizing or omitting this unit's cgroup as a candidate when systemd-oomd needs to act. Requires support for extended attributes (see xattr7) in order to use avoid or omit. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
652
|
+
readonly ManagedOOMPreference?: ManagedOOMPreferenceDirectiveValue;
|
|
653
|
+
/** Specifies how systemd-oomd.service8 will act on this unit's cgroups. Defaults to auto. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
654
|
+
readonly ManagedOOMSwap?: ManagedOOMDirectiveValue;
|
|
655
|
+
/** This setting controls the memory controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
656
|
+
readonly MemoryAccounting?: boolean;
|
|
657
|
+
/** If set, attempts to create memory mappings that are writable and executable at the same time, or to change existing memory mappings to become executable, or mapping shared memory segments as executable, are prohibited. Specifically, a system call filter is added (or preferably, an equivalent kernel check is enabled with prctl(2)) that rejects mmap2 system calls with both PROT_EXEC and PROT_WRITE set, mprotect2 or pkey_mprotect2 system calls with PROT_EXEC set and shmat2 system calls with SHM_EXEC set. Note that this option is incompatible with programs and libraries that generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code "trampoline" feature of various C compilers. This option improves service security, as it makes harder for software exploits to change running code dynamically. However, the protection can be circumvented, if the service can write to a filesystem, which is not mounted with noexec (such as /dev/shm), or it can use memfd_create(). This can be prevented by making such file systems inaccessible to the service (e.g. InaccessiblePaths=/dev/shm) and installing further system call filters (SystemCallFilter=~memfd_create). Note that this feature is fully available on x86-64, and partially on x86. Specifically, the shmat() protection is not available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this option. Specifically, it is recommended to combine this option with SystemCallArchitectures=native or similar. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
658
|
+
readonly MemoryDenyWriteExecute?: boolean;
|
|
659
|
+
/** Best-effort memory throttling threshold for the unit cgroup. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
660
|
+
readonly MemoryHigh?: number | string;
|
|
661
|
+
/** When set, it enables KSM (kernel samepage merging) for the processes. KSM is a memory-saving de-duplication feature. Anonymous memory pages with identical content can be replaced by a single write-protected page. This feature should only be enabled for jobs that share the same security domain. For details, see Kernel Samepage Merging in the kernel documentation. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
662
|
+
readonly MemoryKSM?: boolean;
|
|
663
|
+
/** See systemd.service(5) for MemoryLow=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
664
|
+
readonly MemoryLow?: number | string;
|
|
665
|
+
/** Hard memory usage limit for the unit cgroup. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
666
|
+
readonly MemoryMax?: number | string;
|
|
667
|
+
/** Hard memory protection floor that the kernel should preserve for the unit cgroup. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
668
|
+
readonly MemoryMin?: number | string;
|
|
669
|
+
/** Sets the memory pressure threshold time for memory pressure monitor as configured via MemoryPressureWatch=. Specifies the maximum allocation latency before a memory pressure event is signalled to the service, per 2s window. If not specified, defaults to the DefaultMemoryPressureThresholdSec= setting in systemd-system.conf(5) (which in turn defaults to 200ms). The specified value expects a time unit such as ms or μs, see systemd.time(7) for details on the permitted syntax. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
670
|
+
readonly MemoryPressureThresholdSec?: number | string;
|
|
671
|
+
/** Supports `auto` and `skip` in addition to booleans. Controls whether systemd exposes memory pressure monitoring information to the service environment. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
672
|
+
readonly MemoryPressureWatch?: boolean | "auto" | "skip";
|
|
673
|
+
/** Hard swap usage limit for the unit cgroup. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
674
|
+
readonly MemorySwapMax?: number | string;
|
|
675
|
+
/** Transparent Hugepages (THPs) is a Linux kernel feature that manages memory using larger pages (2MB on x86, compared to the default 4KB). The main goal is to improve memory management efficiency and system performance, especially for memory-intensive applications. However, it can cause drawbacks in some scenarios, such as memory regression and latency spikes. THP policy is governed for the entire system via /sys/kernel/mm/transparent_hugepage/enabled. However, it can be overridden for individual workloads via prctl(2). This directive may be used to disable THPs at process invocation time to stop providing THPs for workloads where the drawbacks outweigh the advantages. When MemoryTHP= is set to inherit or not set at all, systemd inherits THP settings from the process that starts it and no prctl(2) PR_SET_THP_DISABLE call is made. When set to disable, MemoryTHP= disables THPs completely for the process, irrespective of global THP controls. When set to madvise, MemoryTHP= disables THPs for the process except when specifically requested via madvise2 by the process with MADV_HUGEPAGE or MADV_COLLAPSE. When set to system, MemoryTHP= resets the THP policy to system wide policy. This can be used when the process that starts systemd has already disabled THPs via PR_SET_THP_DISABLE, and we want to restore the system default THP setting at process invocation time. For details, see Transparent Hugepage Support in the kernel documentation. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
676
|
+
readonly MemoryTHP?: MemoryTHPDirectiveValue;
|
|
677
|
+
/** Hard zswap usage limit for the unit cgroup. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
678
|
+
readonly MemoryZSwapMax?: number | string;
|
|
679
|
+
/** This setting controls the memory controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
680
|
+
readonly MemoryZSwapWriteback?: boolean;
|
|
681
|
+
/** If on, a private mount namespace for the unit's processes is created and the API file systems /proc/, /sys/, /dev/ and /run/ (as an empty tmpfs) are mounted inside of it, unless they are already mounted. Note that this option has no effect unless used in conjunction with RootDirectory=/RootImage= as these four mounts are generally mounted in the host anyway, and unless the root directory is changed, the private mount namespace will be a 1:1 copy of the host's, and include these four mounts. Note that the /dev/ file system of the host is bind mounted if this option is used without PrivateDevices=. To run the service with a private, minimal version of /dev/, combine this option with PrivateDevices=. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
682
|
+
readonly MountAPIVFS?: boolean;
|
|
683
|
+
/** Takes a mount propagation setting: shared, slave or private, which controls whether file system mount points in the file system namespaces set up for this unit's processes will receive or propagate mounts and unmounts from other file system namespaces. See mount(2) for details on mount propagation, and the three propagation flags in particular. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
684
|
+
readonly MountFlags?: MountPropagationDirectiveValue;
|
|
685
|
+
/** Takes an image policy string as per systemd.image-policy7 to use when mounting the disk images (DDI) specified in RootImage=, MountImage=, ExtensionImage=, respectively. If not specified the following policy string is the default for RootImagePolicy= and MountImagePolicy:. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
686
|
+
readonly MountImagePolicy?: string;
|
|
687
|
+
/** This setting is similar to RootImage= in that it mounts a file system hierarchy from a block device node or loopback file, but the destination directory can be specified as well as mount options. This option expects a whitespace separated list of mount definitions. Each definition consists of a colon-separated tuple of source path and destination definitions, optionally followed by another colon and a list of mount options. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
688
|
+
readonly MountImages?: string | readonly string[];
|
|
689
|
+
/** This setting provides a method for integrating dynamic cgroup, user and group IDs into firewall rules with NFT sets. The benefit of using this setting is to be able to use the IDs as selectors in firewall rules easily and this in turn allows more fine grained filtering. NFT rules for cgroup matching use numeric cgroup IDs, which change every time a service is restarted, making them hard to use in systemd environment otherwise. Dynamic and random IDs used by DynamicUser= can be also integrated with this setting. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
690
|
+
readonly NFTSet?: string | readonly string[];
|
|
691
|
+
/** Controls the NUMA node list which will be applied alongside with selected NUMA policy. Takes a list of NUMA nodes and has the same syntax as a list of CPUs for CPUAffinity= option or special "all" value which will include all available NUMA nodes in the mask. Note that the list of NUMA nodes is not required for default and local policies and for preferred policy we expect a single NUMA node. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
692
|
+
readonly NUMAMask?: string | readonly string[];
|
|
693
|
+
/** Controls the NUMA memory policy of the executed processes. Takes a policy type, one of: default, preferred, bind, interleave and local. A list of NUMA nodes that should be associated with the policy must be specified in NUMAMask=. For more details on each policy please see, set_mempolicy(2). For overall overview of NUMA support in Linux see, numa(7). Source: systemd v260.1, `systemd.exec(5)`. */
|
|
694
|
+
readonly NUMAPolicy?: string | readonly string[];
|
|
695
|
+
/** Takes an absolute file system path referring to a Linux network namespace pseudo-file (i.e. a file like /proc/$PID/ns/net or a bind mount or symlink to one). When set the invoked processes are added to the network namespace referenced by that path. The path has to point to a valid namespace file at the moment the processes are forked off. If this option is used PrivateNetwork= has no effect. If this option is used together with JoinsNamespaceOf= then it only has an effect if this unit is started before any of the listed units that have PrivateNetwork= or NetworkNamespacePath= configured, as otherwise the network namespace of those units is reused. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
696
|
+
readonly NetworkNamespacePath?: string;
|
|
697
|
+
/** Sets the default nice level (scheduling priority) for executed processes. Takes an integer between -20 (highest priority) and 19 (lowest priority). In case of resource contention, smaller values mean more resources will be made available to the unit's processes, larger values mean less resources will be made available. See setpriority(2) for details. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
698
|
+
readonly Nice?: number;
|
|
699
|
+
/** Paths that should be mounted `noexec` for the service. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
700
|
+
readonly NoExecPaths?: string | readonly string[];
|
|
701
|
+
/** If true, ensures that the service process and all its children can never gain new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that a process and its children can never elevate privileges again. Defaults to false. In case the service will be run in a new mount namespace anyway and SELinux is disabled, all file systems are mounted with MS_NOSUID flag. Also see No New Privileges Flag. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
702
|
+
readonly NoNewPrivileges?: boolean;
|
|
703
|
+
/** Set the O_NONBLOCK flag for all file descriptors passed via socket-based activation. If true, all file descriptors >= 3 (i.e. all except stdin, stdout, stderr), excluding those passed in via the file descriptor storage logic (see FileDescriptorStoreMax= for details), will have the O_NONBLOCK flag set and hence are in non-blocking mode. This option is only useful in conjunction with a socket unit, as described in systemd.socket5 and has no effect on file descriptors which were previously saved in the file-descriptor store for example. Defaults to false. Source: systemd v260.1, `systemd.service(5)`. */
|
|
704
|
+
readonly NonBlocking?: boolean;
|
|
705
|
+
/** Controls access to the service status notification socket, as accessible via the sd_notify3 call. Takes one of none (the default), main, exec or all. If none, no daemon status updates are accepted from the service processes, all status update messages are ignored. If main, only service updates sent from the main process of the service are accepted. If exec, only service updates sent from any of the main or control processes originating from one of the Exec*= commands are accepted. If all, all services updates from all members of the service's control group are accepted. This option should be set to open access to the notification socket when using Type=notify/Type=notify-reload or WatchdogSec= (see above). If those options are used but NotifyAccess= is not configured, it will be implicitly set to main. Source: systemd v260.1, `systemd.service(5)`. */
|
|
706
|
+
readonly NotifyAccess?: NotifyAccessDirectiveValue;
|
|
707
|
+
/** Configure the out-of-memory (OOM) killing policy for the kernel and the userspace OOM killer systemd-oomd.service8. On Linux, when memory becomes scarce to the point that the kernel has trouble allocating memory for itself, it might decide to kill a running process in order to free up memory and reduce memory pressure. Note that systemd-oomd.service is a more flexible solution that aims to prevent out-of-memory situations for the userspace too, not just the kernel, by attempting to terminate services earlier, before the kernel would have to act. Source: systemd v260.1, `systemd.service(5)`. */
|
|
708
|
+
readonly OOMPolicy?: OOMPolicyDirectiveValue;
|
|
709
|
+
/** Sets the adjustment value for the Linux kernel's Out-Of-Memory (OOM) killer score for executed processes. Takes an integer between -1000 (to disable OOM killing of processes of this unit) and 1000 (to make killing of processes of this unit under memory pressure very likely). See The /proc Filesystem for details. If not specified, defaults to the OOM score adjustment level of the service manager itself, which is normally at 0. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
710
|
+
readonly OOMScoreAdjust?: number;
|
|
711
|
+
/** Takes an argument of the form path:fd-name:options, where: path is a path to a file or an AF_UNIX socket in the file system; fd-name is a name that will be associated with the file descriptor; the name may contain any ASCII character, but must exclude control characters and ":", and must be at most 255 characters in length; it is optional and, if not provided, defaults to the file name; options is a comma-separated list of access options; possible values are read-only, append, truncate, graceful; if not specified, files will be opened in rw mode; if graceful is specified, errors during file/socket opening are ignored. Specifying the same option several times is treated as an error. The file or socket is opened by the service manager and the file descriptor is passed to the service. If the path is a socket, we call connect() on it. See sd_listen_fds3 for more details on how to retrieve these file descriptors. Source: systemd v260.1, `systemd.service(5)`. */
|
|
712
|
+
readonly OpenFile?: string;
|
|
713
|
+
/** Sets the PAM service name to set up a session as. If set, the executed process will be registered as a PAM session under the specified service name. This is only useful in conjunction with the User= setting, and is otherwise ignored. If not set, no PAM session will be opened for the executed processes. See pam8 for details. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
714
|
+
readonly PAMName?: string;
|
|
715
|
+
/** Takes a path referring to the PID file of the service. Usage of this option is recommended for services where Type= is set to forking. The path specified typically points to a file below /run/. If a relative path is specified for system service, then it is hence prefixed with /run/, and prefixed with $XDG_RUNTIME_DIR if specified in a user service. The service manager will read the PID of the main process of the service from this file after start-up of the service. The service manager will not write to the file configured here, although it will remove the file after the service has shut down if it still exists. The PID file does not need to be owned by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced: the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the PID file must refer to a process already belonging to the service. Source: systemd v260.1, `systemd.service(5)`. */
|
|
716
|
+
readonly PIDFile?: string;
|
|
717
|
+
/** Pass environment variables set for the system service manager to executed processes. Takes a space-separated list of variable names. This option may be specified more than once, in which case all listed variables will be passed. If the empty string is assigned to this option, the list of environment variables to pass is reset, all prior assignments have no effect. Variables specified that are not set for the system manager will not be passed and will be silently ignored. Note that this option is only relevant for the system service manager, as system services by default do not automatically inherit any environment variables set for the service manager itself. However, in case of the user service manager all environment variables are passed to the executed processes anyway, hence this option is without effect for the user service manager. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
718
|
+
readonly PassEnvironment?: string | readonly string[];
|
|
719
|
+
/** Controls which kernel architecture uname2 shall report, when invoked by unit processes. Takes one of the architecture identifiers arm64, arm64-be, arm, arm-be, x86, x86-64, ppc, ppc-le, ppc64, ppc64-le, s390 or s390x. Which personality architectures are supported depends on the kernel's native architecture. Usually the 64-bit versions of the various system architectures support their immediate 32-bit personality architecture counterpart, but no others. For example, x86-64 systems support the x86-64 and x86 personalities but no others. The personality feature is useful when running 32-bit services on a 64-bit host system. If not specified, the personality is left unmodified and thus reflects the personality of the host system's kernel. This option is not useful on architectures for which only one native word width was ever available, such as m68k (32-bit only) or alpha (64-bit only). Source: systemd v260.1, `systemd.exec(5)`. */
|
|
720
|
+
readonly Personality?: string;
|
|
721
|
+
/** If set, mount a private instance of the BPF filesystem on /sys/fs/bpf/, effectively hiding the host bpffs which contains information about loaded programs and maps. Otherwise, if ProtectKernelTunables= is set, the instance from the host is inherited but mounted read-only. Defaults to false. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
722
|
+
readonly PrivateBPF?: boolean;
|
|
723
|
+
/** If true, sets up a new /dev/ mount for the executed processes and only adds API pseudo devices such as /dev/null, /dev/zero or /dev/random (as well as the pseudo TTY subsystem) to it, but no physical devices such as /dev/sda, system memory /dev/mem, system ports /dev/port and others. This is useful to turn off physical device access by the executed process. Defaults to false. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
724
|
+
readonly PrivateDevices?: boolean;
|
|
725
|
+
/** If true, sets up a new IPC namespace for the executed processes. Each IPC namespace has its own set of System V IPC identifiers and its own POSIX message queue file system. This is useful to avoid name clash of IPC identifiers. Defaults to false. It is possible to run two or more units within the same private IPC namespace by using the JoinsNamespaceOf= directive, see systemd.unit5 for details. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
726
|
+
readonly PrivateIPC?: boolean;
|
|
727
|
+
/** Takes a boolean parameter. If set, the processes of this unit will be run in their own private file system (mount) namespace with all mount propagation from the processes towards the host's main file system namespace turned off. This means any file system mount points established or removed by the unit's processes will be private to them and not be visible to the host. However, file system mount points established or removed on the host will be propagated to the unit's processes. See mount_namespaces(7) for details on file system namespaces. Defaults to off. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
728
|
+
readonly PrivateMounts?: boolean;
|
|
729
|
+
/** If true, sets up a new network namespace for the executed processes and configures only the loopback network device lo inside it. No other network devices will be available to the executed process. This is useful to turn off network access by the executed process. Defaults to false. It is possible to run two or more units within the same private network namespace by using the JoinsNamespaceOf= directive, see systemd.unit5 for details. Note that this option will disconnect all socket families from the host, including AF_NETLINK and AF_UNIX. Effectively, for AF_NETLINK this means that device configuration events received from systemd-udevd.service8 are not delivered to the unit's processes. And for AF_UNIX this has the effect that AF_UNIX sockets in the abstract socket namespace of the host will become unavailable to the unit's processes (however, those located in the file system will continue to be accessible). Source: systemd v260.1, `systemd.exec(5)`. */
|
|
730
|
+
readonly PrivateNetwork?: boolean;
|
|
731
|
+
/** Defaults to false. If enabled, sets up a new PID namespace for the executed processes. Each executed process is now PID 1 - the init process - in the new namespace. /proc/ is mounted such that only processes in the PID namespace are visible. If PrivatePIDs= is set, MountAPIVFS=yes is implied. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
732
|
+
readonly PrivatePIDs?: boolean;
|
|
733
|
+
/** Supports `disconnected` in addition to booleans. Isolates `/tmp` and `/var/tmp` for this unit, and cleans up temporary files when the service stops. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
734
|
+
readonly PrivateTmp?: boolean | "disconnected";
|
|
735
|
+
/** Supports `self`, `identity`, `full`, and `managed` in addition to booleans. Runs the service in a separate user namespace with a configured UID/GID mapping. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
736
|
+
readonly PrivateUsers?: boolean | "self" | "identity" | "full" | "managed";
|
|
737
|
+
/** Takes one of all (the default) and pid. If pid, all files and directories not directly associated with process management and introspection are made invisible in the /proc/ file system configured for the unit's processes. This controls the subset= mount option of the procfs instance for the unit. For further details see The /proc Filesystem. Note that Linux exposes various kernel APIs via /proc/, which are made unavailable with this setting. Since these APIs are used frequently this option is useful only in a few, specific cases, and is not suitable for most non-trivial programs. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
738
|
+
readonly ProcSubset?: ProcSubsetDirectiveValue;
|
|
739
|
+
/** If set, writes to the hardware clock or system clock will be denied. Defaults to off. Enabling this option removes CAP_SYS_TIME and CAP_WAKE_ALARM from the capability bounding set for this unit, installs a system call filter to block calls that can set the clock, and DeviceAllow=char-rtc r is implied. Note that the system calls are blocked altogether, the filter does not take into account that some of the calls can be used to read the clock state with some parameter combinations. Effectively, /dev/rtc0, /dev/rtc1, etc. are made read-only to the service. See systemd.resource-control5 for the details about DeviceAllow=. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
740
|
+
readonly ProtectClock?: boolean;
|
|
741
|
+
/** Supports `private` and `strict` in addition to booleans. Limits how the service can access `/sys/fs/cgroup`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
742
|
+
readonly ProtectControlGroups?: boolean | "private" | "strict";
|
|
743
|
+
/** Supports `read-only` and `tmpfs` in addition to booleans. Restricts how the service can access `/home`, `/root`, and `/run/user`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
744
|
+
readonly ProtectHome?: boolean | "read-only" | "tmpfs";
|
|
745
|
+
/** Supports `private` and optional `:hostname` syntax in addition to booleans. Controls whether the service gets its own UTS namespace and hostname. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
746
|
+
readonly ProtectHostname?: boolean | string;
|
|
747
|
+
/** If true, access to the kernel log ring buffer will be denied. It is recommended to turn this on for most services that do not need to read from or write to the kernel log ring buffer. Enabling this option removes CAP_SYSLOG from the capability bounding set for this unit, and installs a system call filter to block the syslog2 system call (not to be confused with the libc API syslog3 for userspace logging). The kernel exposes its log buffer to userspace via /dev/kmsg and /proc/kmsg. If enabled, these are made inaccessible to all the processes in the unit. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
748
|
+
readonly ProtectKernelLogs?: boolean;
|
|
749
|
+
/** If true, explicit module loading will be denied. This allows module load and unload operations to be turned off on modular kernels. It is recommended to turn this on for most services that do not need special file systems or extra kernel modules to work. Defaults to off. Enabling this option removes CAP_SYS_MODULE from the capability bounding set for the unit, and installs a system call filter to block module system calls, also /usr/lib/modules is made inaccessible. For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. Note that limited automatic module loading due to user configuration or kernel mapping tables might still happen as side effect of requested user operations, both privileged and unprivileged. To disable module auto-load feature please see sysctl.d5 kernel.modules_disabled mechanism and /proc/sys/kernel/modules_disabled documentation. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
750
|
+
readonly ProtectKernelModules?: boolean;
|
|
751
|
+
/** If true, kernel variables accessible through /proc/sys/, /sys/, /proc/sysrq-trigger, /proc/latency_stats, /proc/acpi, /proc/timer_stats, /proc/fs and /proc/irq will be made read-only and /proc/kallsyms as well as /proc/kcore will be inaccessible to all processes of the unit. Usually, tunable kernel variables should be initialized only at boot-time, for example with the sysctl.d5 mechanism. Few services need to write to these at runtime; it is hence recommended to turn this on for most services. For this setting the same restrictions regarding mount propagation and privileges apply as for ReadOnlyPaths= and related calls, see above. Defaults to off. Note that this option does not prevent indirect changes to kernel tunables affected by IPC calls to other processes. However, `InaccessiblePaths=` may be used to make relevant IPC file system objects inaccessible. If ProtectKernelTunables= is set, MountAPIVFS=yes is implied. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
752
|
+
readonly ProtectKernelTunables?: boolean;
|
|
753
|
+
/** Takes one of noaccess, invisible, ptraceable or default (which it defaults to). When set, this controls the hidepid= mount option of the procfs instance for the unit that controls which directories with process metainformation (/proc/PID) are visible and accessible: when set to noaccess the ability to access most of other users' process metadata in /proc/ is taken away for processes of the service. When set to invisible processes owned by other users are hidden from /proc/. If ptraceable all processes that cannot be ptrace()'ed by a process are hidden to it. If default no restrictions on /proc/ access or visibility are made. For further details see The /proc Filesystem. It is generally recommended to run most system services with this option set to invisible. This option is implemented via file system namespacing, and thus cannot be used with services that shall be able to install mount points in the host file system hierarchy. Note that the root user is unaffected by this option, so to be effective it has to be used together with User= or DynamicUser=yes, and also without the CAP_SYS_PTRACE capability, which also allows a process to bypass this feature. It cannot be used for services that need to access metainformation about other users' processes. This option implies MountAPIVFS=. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
754
|
+
readonly ProtectProc?: ProtectProcDirectiveValue;
|
|
755
|
+
/** Supports `full` and `strict` in addition to booleans. Mounts increasingly large parts of the host file system read-only for this unit. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
756
|
+
readonly ProtectSystem?: boolean | "full" | "strict";
|
|
757
|
+
/** Paths that should be made read-only inside the unit file-system namespace. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
758
|
+
readonly ReadOnlyPaths?: string | readonly string[];
|
|
759
|
+
/** Paths that should remain writable even when broader protections such as `ProtectSystem=` are enabled. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
760
|
+
readonly ReadWritePaths?: string | readonly string[];
|
|
761
|
+
/** Supports either booleans or a space-separated list of refreshable resource kinds such as `extensions` and `credentials`. Source: systemd v260.1, `systemd.service(5)`. */
|
|
762
|
+
readonly RefreshOnReload?: boolean | string;
|
|
763
|
+
/** Configures the UNIX process signal to send to the service's main process when asked to reload the service's configuration. Defaults to SIGHUP. This option has no effect unless Type=notify-reload is used, see above. Source: systemd v260.1, `systemd.service(5)`. */
|
|
764
|
+
readonly ReloadSignal?: NodeJS.Signals | number;
|
|
765
|
+
/** Takes a boolean value that specifies whether the service shall be considered active even when all its processes exited. Defaults to no. Source: systemd v260.1, `systemd.service(5)`. */
|
|
766
|
+
readonly RemainAfterExit?: boolean;
|
|
767
|
+
/** Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and group the processes of this unit are run as are removed when the unit is stopped. This setting only has an effect if at least one of User=, Group= and DynamicUser= are used. It has no effect on IPC objects owned by the root user. Specifically, this removes System V semaphores, as well as System V and POSIX shared memory segments and message queues. If multiple units use the same user or group the IPC objects are removed when the last of these units is stopped. This setting is implied if DynamicUser= is set. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
768
|
+
readonly RemoveIPC?: boolean;
|
|
769
|
+
/** Configures whether the service shall be restarted when the service process exits, is killed, or a timeout is reached. The service process may be the main service process, but it may also be one of the processes specified with ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload=. When the death of the process is a result of systemd operation (e.g. service stop or restart), the service will not be restarted. Timeouts include missing the watchdog "keep-alive ping" deadline and a service start, reload, and stop operation timeouts. Source: systemd v260.1, `systemd.service(5)`. */
|
|
770
|
+
readonly Restart?: ServiceRestartDirectiveValue;
|
|
771
|
+
/** Takes a list of exit status definitions that, when returned by the main service process, will force automatic service restarts, regardless of the restart setting configured with Restart=. The argument format is similar to RestartPreventExitStatus=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
772
|
+
readonly RestartForceExitStatus?: string | number | readonly (string | number)[];
|
|
773
|
+
/** Specifies which signal to use when restarting a service. The same as KillSignal= described above, with the exception that this setting is used in a restart job. Not set by default, and the value of KillSignal= is used. Source: systemd v260.1, `systemd.kill(5)`. */
|
|
774
|
+
readonly RestartKillSignal?: NodeJS.Signals | number;
|
|
775
|
+
/** Configures the longest time to sleep before restarting a service as the interval goes up with RestartSteps=. Takes a value in the same format as RestartSec=, or infinity to disable the setting. Defaults to infinity. Source: systemd v260.1, `systemd.service(5)`. */
|
|
776
|
+
readonly RestartMaxDelaySec?: number | string;
|
|
777
|
+
/** Takes a string value that specifies how a service should restart: If set to normal (the default), the service restarts by going through a failed/inactive state. If set to direct, the service transitions to the activating state directly during auto-restart, skipping failed/inactive state. ExecStopPost= is still invoked. OnSuccess= and OnFailure= are skipped. This option is useful in cases where a dependency can fail temporarily but we do not want these temporary failures to make the dependent units fail. Dependent units are not notified of these temporary failures. If set to debug, the service manager will log messages that are related to this unit at debug level while automated restarts are attempted, until either the service hits the rate limit or it succeeds, and the $DEBUG_INVOCATION=1 environment variable will be set for the unit. This is useful to be able to get additional information when a service fails to start, without needing to proactively or permanently enable debug level logging in systemd, which is very verbose. This is otherwise equivalent to normal mode. Source: systemd v260.1, `systemd.service(5)`. */
|
|
778
|
+
readonly RestartMode?: ServiceRestartModeDirectiveValue;
|
|
779
|
+
/** Takes a list of exit status definitions that, when returned by the main service process, will prevent automatic service restarts, regardless of the restart setting configured with Restart=. Exit status definitions can be numeric termination statuses, termination status names, or termination signal names, separated by spaces. Defaults to the empty list, so that, by default, no exit status is excluded from the configured restart logic. A service with the RestartPreventExitStatus= setting RestartPreventExitStatus=TEMPFAIL 250 SIGKILL Exit status 75 (TEMPFAIL), 250, and the termination signal SIGKILL will not result in automatic service restarting. This option may appear more than once, in which case the list of restart-preventing statuses is merged. If the empty string is assigned to this option, the list is reset and all prior assignments of this option will have no effect. Source: systemd v260.1, `systemd.service(5)`. */
|
|
780
|
+
readonly RestartPreventExitStatus?: string | number | readonly (string | number)[];
|
|
781
|
+
/** Configures the time to sleep before restarting a service (as configured with Restart=). Takes a unit-less value in seconds, or a time span value such as "5min 20s". Defaults to 100ms. Source: systemd v260.1, `systemd.service(5)`. */
|
|
782
|
+
readonly RestartSec?: number | string;
|
|
783
|
+
/** Configures the number of exponential steps to take to increase the interval of auto-restarts from RestartSec= to RestartMaxDelaySec=. Takes a positive integer or 0 to disable it. Defaults to 0. Hint: values between 3 and 5 are good choices when exponential backoff is desired. Source: systemd v260.1, `systemd.service(5)`. */
|
|
784
|
+
readonly RestartSteps?: number;
|
|
785
|
+
/** Restricts the set of socket address families accessible to the processes of this unit. Takes none, or a space-separated list of address family names to allow-list, such as AF_UNIX, AF_INET or AF_INET6, see address_families7 for all possible options. When none is specified, then all address families will be denied. When prefixed with ~ the listed address families will be applied as deny list, otherwise as allow list. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
786
|
+
readonly RestrictAddressFamilies?: string | readonly string[];
|
|
787
|
+
/** Restricts the set of filesystems processes of this unit can open files on. Takes a space-separated list of filesystem names. Any filesystem listed is made accessible to the unit's processes, access to filesystem types not listed is prohibited (allow-listing). If the first character of the list is ~, the effect is inverted: access to the filesystems listed is prohibited (deny-listing). If the empty string is assigned, access to filesystems is not restricted. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
788
|
+
readonly RestrictFileSystems?: string | readonly string[];
|
|
789
|
+
/** Restricts access to Linux namespace functionality for the processes of this unit. For details about Linux namespaces, see namespaces(7). Either takes a boolean argument, or a space-separated list of namespace type identifiers. If false (the default), no restrictions on namespace creation and switching are made. If true, access to any kind of namespacing is prohibited. Otherwise, a space-separated list of namespace type identifiers must be specified, consisting of any combination of: cgroup, ipc, net, mnt, pid, user, uts, and time. Any namespace type listed is made accessible to the unit's processes, access to namespace types not listed is prohibited (allow-listing). By prepending the list with a single tilde character (~) the effect may be inverted: only the listed namespace types will be made inaccessible, all unlisted ones are permitted (deny-listing). If the empty string is assigned, the default namespace restrictions are applied, which is equivalent to false. This option may appear more than once, in which case the namespace types are merged by OR, or by AND if the lines are prefixed with ~ (see examples below). Internally, this setting limits access to the unshare2, clone2 and setns2 system calls, taking the specified flags parameters into account. Note that — if this option is used — in addition to restricting creation and switching of the specified types of namespaces (or all of them, if true) access to the setns() system call with a zero flags parameter is prohibited. This setting is only supported on x86, x86-64, mips, mips-le, mips64, mips64-le, mips64-n32, mips64-le-n32, ppc64, ppc64-le, s390 and s390x, and enforces no restrictions on other architectures. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
790
|
+
readonly RestrictNamespaces?: boolean | string | readonly string[];
|
|
791
|
+
/** Takes a list of space-separated network interface names. This option restricts the network interfaces that processes of this unit can use. By default, processes can only use the network interfaces listed (allow-list). If the first character of the rule is ~, the effect is inverted: the processes can only use network interfaces not listed (deny-list). Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
792
|
+
readonly RestrictNetworkInterfaces?: string | readonly string[];
|
|
793
|
+
/** If set, any attempts to enable realtime scheduling in a process of the unit are refused. This restricts access to realtime task scheduling policies such as SCHED_FIFO, SCHED_RR or SCHED_DEADLINE. See sched7 for details about these scheduling policies. Realtime scheduling policies may be used to monopolize CPU time for longer periods of time, and may hence be used to lock up or otherwise trigger Denial-of-Service situations on the system. It is hence recommended to restrict access to realtime scheduling to the few programs that actually require them. Defaults to off. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
794
|
+
readonly RestrictRealtime?: boolean;
|
|
795
|
+
/** If set, any attempts to set the set-user-ID (SUID) or set-group-ID (SGID) bits on files or directories will be denied (for details on these bits see inode7). As the SUID/SGID bits are mechanisms to elevate privileges, and allow users to acquire the identity of other users, it is recommended to restrict creation of SUID/SGID files to the few programs that actually require them. Note that this restricts marking of any type of file system object with these bits, including both regular files and directories (where the SGID is a different meaning than for files, see documentation). This option is implied if DynamicUser= is enabled. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
796
|
+
readonly RestrictSUIDSGID?: boolean;
|
|
797
|
+
/** Takes a directory path relative to the host's root directory (i.e. the root of the system running the service manager). Sets the root directory for executed processes, with the pivot_root2 or chroot2 system call. If this is used, it must be ensured that the process binary and all its auxiliary files are available in the new root. Note that setting this parameter might result in additional dependencies to be added to the unit (see above). Source: systemd v260.1, `systemd.exec(5)`. */
|
|
798
|
+
readonly RootDirectory?: string;
|
|
799
|
+
/** If true, the root directory, as configured with the RootDirectory= option (see systemd.exec5 for more information), is only applied to the process started with ExecStart=, and not to the various other ExecStartPre=, ExecStartPost=, ExecReload=, ExecReloadPost=, ExecStop=, and ExecStopPost= commands. If false, the setting is applied to all configured commands the same way. Defaults to false. Source: systemd v260.1, `systemd.service(5)`. */
|
|
800
|
+
readonly RootDirectoryStartOnly?: boolean;
|
|
801
|
+
/** If enabled, executed processes will run in an ephemeral copy of the root directory or root image. The ephemeral copy is placed in /var/lib/systemd/ephemeral-trees/ while the service is active and is cleaned up when the service is stopped or restarted. If RootDirectory= is used and the root directory is a subvolume, the ephemeral copy will be created by making a snapshot of the subvolume. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
802
|
+
readonly RootEphemeral?: boolean;
|
|
803
|
+
/** Takes a data integrity (dm-verity) root hash specified in hexadecimal, or the path to a file containing a root hash in ASCII hexadecimal format. This option enables data integrity checks using dm-verity, if the used image contains the appropriate integrity data (see above) or if RootVerity= is used. The specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64 formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but the image file carries the user.verity.roothash extended file attribute (see xattr7), then the root hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or is not supported by the underlying file system), but a file with the .roothash suffix is found next to the image file, bearing otherwise the same name (except if the image has the .raw suffix, in which case the root hash file must not have it in its name), the root hash is read from it and automatically used, also as formatted hexadecimal characters. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
804
|
+
readonly RootHash?: string;
|
|
805
|
+
/** Takes a PKCS7 signature of the RootHash= option as a path to a DER-encoded signature file, or as an ASCII base64 string encoding of a DER-encoded signature prefixed by base64:. The dm-verity volume will only be opened if the signature of the root hash is valid and signed by a public key present in the kernel keyring. If this option is not specified, but a file with the .roothash.p7s suffix is found next to the image file, bearing otherwise the same name (except if the image has the .raw suffix, in which case the signature file must not have it in its name), the signature is read from it and automatically used. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
806
|
+
readonly RootHashSignature?: string;
|
|
807
|
+
/** Takes a path to a block device node or regular file as argument. This call is similar to RootDirectory= however mounts a file system hierarchy from a block device node or loopback file instead of a directory. The device node or file system image file needs to contain a file system without a partition table, or a file system within an MBR/MS-DOS or GPT partition table with only a single Linux-compatible partition, or a set of file systems within a GPT partition table that follows the UAPI.2 Discoverable Partitions Specification. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
808
|
+
readonly RootImage?: string;
|
|
809
|
+
/** Takes a comma-separated list of mount options that will be used on disk images specified by RootImage=. Optionally a partition name can be prefixed, followed by colon, in case the image has multiple partitions, otherwise partition name root is implied. Options for multiple partitions can be specified in a single line with space separators. Assigning an empty string removes previous assignments. For a list of valid mount options, please refer to mount8. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
810
|
+
readonly RootImageOptions?: string;
|
|
811
|
+
/** Takes an image policy string as per systemd.image-policy7 to use when mounting the disk images (DDI) specified in RootImage=, MountImage=, ExtensionImage=, respectively. If not specified the following policy string is the default for RootImagePolicy= and MountImagePolicy:. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
812
|
+
readonly RootImagePolicy?: string;
|
|
813
|
+
/** Takes a path to a systemd.mstack7 directory encapsulating a mount stack consisting of layers and bind mounts. Similar to RootDirectory= and RootImage= this runs the service off a distinct root file system, in this case set up via overlayfs. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
814
|
+
readonly RootMStack?: string;
|
|
815
|
+
/** Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks using dm-verity, if RootImage= is used and a root-hash is passed and if the used image itself does not contain the integrity data. The integrity data must be matched by the root hash. If this option is not specified, but a file with the .verity suffix is found next to the image file, bearing otherwise the same name (except if the image has the .raw suffix, in which case the verity data file must not have it in its name), the verity data is read from it and automatically used. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
816
|
+
readonly RootVerity?: string;
|
|
817
|
+
/** Relative runtime-state directories to create for the service under `/run`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
818
|
+
readonly RuntimeDirectory?: string;
|
|
819
|
+
/** File mode to apply to directories created by `RuntimeDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
820
|
+
readonly RuntimeDirectoryMode?: string;
|
|
821
|
+
/** Supports `restart` in addition to booleans. Controls whether `RuntimeDirectory=` entries survive stops and restarts. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
822
|
+
readonly RuntimeDirectoryPreserve?: boolean | "restart";
|
|
823
|
+
/** Configures a maximum time for the service to run. If this is used and the service has been active for longer than the specified time it is terminated and put into a failure state. Note that this setting does not have any effect on Type=oneshot services, as they terminate immediately after activation completed (use TimeoutStartSec= to limit their activation). Pass infinity (the default) to configure no runtime limit. Source: systemd v260.1, `systemd.service(5)`. */
|
|
824
|
+
readonly RuntimeMaxSec?: number | string;
|
|
825
|
+
/** This option modifies RuntimeMaxSec= by increasing the maximum runtime by an evenly distributed duration between 0 and the specified value (in seconds). If RuntimeMaxSec= is unspecified, then this feature will be disabled. Source: systemd v260.1, `systemd.service(5)`. */
|
|
826
|
+
readonly RuntimeRandomizedExtraSec?: number | string;
|
|
827
|
+
/** Set the SELinux security context of the executed process. If set, this will override the automated domain transition. However, the policy still needs to authorize the transition. This directive is ignored if SELinux is disabled. If prefixed by -, failing to set the SELinux security context will be ignored, but it is still possible that the subsequent execve() may fail if the policy does not allow the transition for the non-overridden context. This does not affect commands prefixed with +. See setexeccon3 for details. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
828
|
+
readonly SELinuxContext?: string;
|
|
829
|
+
/** Controls the secure bits set for the executed process. Takes a space-separated combination of options from the following list: keep-caps, keep-caps-locked, no-setuid-fixup, no-setuid-fixup-locked, noroot, and noroot-locked. This option may appear more than once, in which case the secure bits are ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect commands prefixed with +. See capabilities(7) for details. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
830
|
+
readonly SecureBits?: string | readonly string[];
|
|
831
|
+
/** Specifies whether to send SIGHUP to remaining processes immediately after sending the signal configured with KillSignal=. This is useful to indicate to shells and shell-like programs that their connection has been severed. Takes a boolean value. Defaults to no. Source: systemd v260.1, `systemd.kill(5)`. */
|
|
832
|
+
readonly SendSIGHUP?: boolean;
|
|
833
|
+
/** Specifies whether to send SIGKILL (or the signal specified by FinalKillSignal=) to remaining processes after a timeout, if the normal shutdown procedure left processes of the service around. When disabled, a KillMode= of control-group or mixed service will not restart if processes from prior services exist within the control group. Takes a boolean value. Defaults to yes. Source: systemd v260.1, `systemd.kill(5)`. */
|
|
834
|
+
readonly SendSIGKILL?: boolean;
|
|
835
|
+
/** Similar to `LoadCredential=`, but accepts a literal value to use as data for the credential, instead of a file system path to read the data from. Do not use this option for data that is supposed to be secret, as it is accessible to unprivileged processes via IPC. It's only safe to use this for user IDs, public key material and similar non-sensitive data. For everything else use LoadCredential=. In order to embed binary data into the credential data use C-style escaping (i.e. \n to embed a newline, or \x00 to embed a NUL byte). Source: systemd v260.1, `systemd.exec(5)`. */
|
|
836
|
+
readonly SetCredential?: string | readonly string[];
|
|
837
|
+
/** Similar to `LoadCredential=`, but accepts a literal value to use as data for the credential, instead of a file system path to read the data from. Do not use this option for data that is supposed to be secret, as it is accessible to unprivileged processes via IPC. It's only safe to use this for user IDs, public key material and similar non-sensitive data. For everything else use LoadCredential=. In order to embed binary data into the credential data use C-style escaping (i.e. \n to embed a newline, or \x00 to embed a NUL byte). Source: systemd v260.1, `systemd.exec(5)`. */
|
|
838
|
+
readonly SetCredentialEncrypted?: string | readonly string[];
|
|
839
|
+
/** Takes a boolean parameter that controls whether to set the $HOME, $LOGNAME, and $SHELL environment variables. If not set, this defaults to true if User=, DynamicUser= or PAMName= are set, false otherwise. If set to true, the variables will always be set for system services, i.e. even when the default user root is used. If set to false, the mentioned variables are not set by the service manager, no matter whether User=, DynamicUser=, or PAMName= are used or not. This option normally has no effect on services of the per-user service manager, since in that case these variables are typically inherited from user manager's own environment anyway. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
840
|
+
readonly SetLoginEnvironment?: boolean;
|
|
841
|
+
/** The name of the slice unit to place the unit in. Defaults to system.slice for all non-instantiated units of all unit types (except for slice units themselves see below). Instance units are by default placed in a subslice of system.slice that is named after the template name. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
842
|
+
readonly Slice?: string;
|
|
843
|
+
/** Takes a SMACK64 security label as argument. The process executed by the unit will be started under this label and SMACK will decide whether the process is allowed to run or not, based on it. The process will continue to run under the label specified here unless the executable has its own SMACK64EXEC label, in which case the process will transition to run under that label. When not specified, the label that systemd is running under is used. This directive is ignored if SMACK is disabled. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
844
|
+
readonly SmackProcessLabel?: string;
|
|
845
|
+
/** Configures restrictions on the ability of unit processes to invoke bind2 on a socket. Both allow and deny rules to be defined that restrict which addresses a socket may be bound to. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
846
|
+
readonly SocketBindAllow?: string | readonly string[];
|
|
847
|
+
/** See systemd.service(5) for SocketBindDeny=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
848
|
+
readonly SocketBindDeny?: string | readonly string[];
|
|
849
|
+
/** Specifies the name of the socket units this service shall inherit socket file descriptors from when the service is started. Normally, it should not be necessary to use this setting, as all socket file descriptors whose unit shares the same name as the service (subject to the different unit name suffix of course) are passed to the spawned process. Source: systemd v260.1, `systemd.service(5)`. */
|
|
850
|
+
readonly Sockets?: string | readonly string[];
|
|
851
|
+
/** Controls where file descriptor 2 (stderr) of the executed processes is connected to. The available options are identical to those of StandardOutput=, with some exceptions: if set to inherit the file descriptor used for standard output is duplicated for standard error, while fd:name will use a default file descriptor name of stderr. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
852
|
+
readonly StandardError?: StandardErrorDirectiveValue;
|
|
853
|
+
/** Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one of null, tty, tty-force, tty-fail, data, file:path, socket or fd:name. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
854
|
+
readonly StandardInput?: StandardInputDirectiveValue;
|
|
855
|
+
/** Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to the executed processes. These settings have no effect unless StandardInput= is set to data (which is the default if StandardInput= is not set otherwise, but StandardInputText=/StandardInputData= is). Use this option to embed process input data directly in the unit file. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
856
|
+
readonly StandardInputData?: string | readonly string[];
|
|
857
|
+
/** Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to the executed processes. These settings have no effect unless StandardInput= is set to data (which is the default if StandardInput= is not set otherwise, but StandardInputText=/StandardInputData= is). Use this option to embed process input data directly in the unit file. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
858
|
+
readonly StandardInputText?: string | readonly string[];
|
|
859
|
+
/** Controls where file descriptor 1 (stdout) of the executed processes is connected to. Takes one of inherit, null, tty, journal, kmsg, journal+console, kmsg+console, file:path, append:path, truncate:path, socket or fd:name. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
860
|
+
readonly StandardOutput?: StandardOutputDirectiveValue;
|
|
861
|
+
/** This setting controls the cpuset controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
862
|
+
readonly StartupAllowedCPUs?: string;
|
|
863
|
+
/** These settings control the cpuset controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
864
|
+
readonly StartupAllowedMemoryNodes?: string;
|
|
865
|
+
/** See systemd.service(5) for StartupCPUWeight=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
866
|
+
readonly StartupCPUWeight?: number | string;
|
|
867
|
+
/** See systemd.service(5) for StartupIOWeight=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
868
|
+
readonly StartupIOWeight?: number | string;
|
|
869
|
+
/** See systemd.service(5) for StartupMemoryHigh=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
870
|
+
readonly StartupMemoryHigh?: number | string;
|
|
871
|
+
/** See systemd.service(5) for StartupMemoryLow=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
872
|
+
readonly StartupMemoryLow?: number | string;
|
|
873
|
+
/** See systemd.service(5) for StartupMemoryMax=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
874
|
+
readonly StartupMemoryMax?: number | string;
|
|
875
|
+
/** See systemd.service(5) for StartupMemorySwapMax=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
876
|
+
readonly StartupMemorySwapMax?: number | string;
|
|
877
|
+
/** See systemd.service(5) for StartupMemoryZSwapMax=. Source: systemd v260.1, `systemd.service(5)`. */
|
|
878
|
+
readonly StartupMemoryZSwapMax?: number | string;
|
|
879
|
+
/** Relative persistent-state directories to create for the service under `/var/lib`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
880
|
+
readonly StateDirectory?: string;
|
|
881
|
+
/** Enables project-quota accounting for directories created by `StateDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
882
|
+
readonly StateDirectoryAccounting?: boolean;
|
|
883
|
+
/** File mode to apply to directories created by `StateDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
884
|
+
readonly StateDirectoryMode?: string;
|
|
885
|
+
/** Storage quota for directories created by `StateDirectory=`. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
886
|
+
readonly StateDirectoryQuota?: number | string;
|
|
887
|
+
/** Takes a list of exit status definitions that, when returned by the main service process, will be considered successful termination, in addition to the normal successful exit status 0 and, except for Type=oneshot, the signals SIGHUP, SIGINT, SIGTERM, and SIGPIPE. Exit status definitions can be numeric termination statuses, termination status names, or termination signal names, separated by spaces. See the Process Exit Codes section in systemd.exec5 for a list of termination status names (for this setting only the part without the EXIT_ or EX_ prefix should be used). See signal(7) for a list of signal names. Source: systemd v260.1, `systemd.service(5)`. */
|
|
888
|
+
readonly SuccessExitStatus?: string | number | readonly (string | number)[];
|
|
889
|
+
/** Sets the supplementary Unix groups the processes are executed as. This takes a space-separated list of group names or IDs. This option may be specified more than once, in which case all listed groups are set as supplementary groups. When the empty string is assigned, the list of supplementary groups is reset, and all assignments prior to this one will have no effect. In any way, this option does not override, but extends the list of supplementary groups configured in the system group database for the user. This does not affect commands prefixed with +. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
890
|
+
readonly SupplementaryGroups?: string | readonly string[];
|
|
891
|
+
/** Sets the syslog facility identifier to use when logging. One of kern, user, mail, daemon, auth, syslog, lpr, news, uucp, cron, authpriv, ftp, local0, local1, local2, local3, local4, local5, local6 or local7. See syslog3 for details. This option is only useful when StandardOutput= or StandardError= are set to journal or kmsg (or to the same settings in combination with +console), and only applies to log messages written to stdout or stderr. Defaults to daemon. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
892
|
+
readonly SyslogFacility?: SyslogFacilityDirectiveValue;
|
|
893
|
+
/** Sets the process name ("syslog tag") to prefix log lines sent to the logging system or the kernel log buffer with. If not set, defaults to the process name of the executed process. This option is only useful when StandardOutput= or StandardError= are set to journal or kmsg (or to the same settings in combination with +console) and only applies to log messages written to stdout or stderr. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
894
|
+
readonly SyslogIdentifier?: string;
|
|
895
|
+
/** The default syslog log level to use when logging to the logging system or the kernel log buffer. One of emerg, alert, crit, err, warning, notice, info, debug. See syslog3 for details. This option is only useful when StandardOutput= or StandardError= are set to journal or kmsg (or to the same settings in combination with +console), and only applies to log messages written to stdout or stderr. Note that individual lines output by executed processes may be prefixed with a different log level which can be used to override the default log level specified here. The interpretation of these prefixes may be disabled with SyslogLevelPrefix=, see below. For details, see sd-daemon3. Defaults to info. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
896
|
+
readonly SyslogLevel?: SyslogLevelDirectiveValue;
|
|
897
|
+
/** If true and StandardOutput= or StandardError= are set to journal or kmsg (or to the same settings in combination with +console), log lines written by the executed process that are prefixed with a log level will be processed with this log level set but the prefix removed. If set to false, the interpretation of these prefixes is disabled and the logged lines are passed on as-is. This only applies to log messages written to stdout or stderr. For details about this prefixing see sd-daemon3. Defaults to true. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
898
|
+
readonly SyslogLevelPrefix?: boolean;
|
|
899
|
+
/** Takes a space-separated list of architecture identifiers to include in the system call filter. The known architecture identifiers are the same as for ConditionArchitecture= described in systemd.unit5, as well as x32, mips64-n32, mips64-le-n32, and the special identifier native. The special identifier native implicitly maps to the native architecture of the system (or more precisely: to the architecture the system manager is compiled for). By default, this option is set to the empty list, i.e. no filtering is applied. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
900
|
+
readonly SystemCallArchitectures?: string | readonly string[];
|
|
901
|
+
/** Takes an errno error number (between 1 and 4095) or errno name such as EPERM, EACCES or EUCLEAN, to return when the system call filter configured with SystemCallFilter= is triggered, instead of terminating the process immediately. See errno3 for a full list of error codes. When this setting is not used, or when the empty string or the special setting kill is assigned, the process will be terminated immediately when the filter is triggered. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
902
|
+
readonly SystemCallErrorNumber?: string;
|
|
903
|
+
/** Takes a space-separated list of system call names or system call groups. If this setting is used, system calls executed by the unit processes except for the listed ones will result in the system call being denied (allow-listing). If the first character of the list is ~, the effect is inverted: only the listed system calls will be denied (deny-listing). This option may be specified more than once, in which case the filter masks are merged. If the empty string is assigned, the filter is reset, all prior assignments will have no effect. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
904
|
+
readonly SystemCallFilter?: string | readonly string[];
|
|
905
|
+
/** Takes a space-separated list of system call names. If this setting is used, all system calls executed by the unit processes for the listed ones will be logged. If the first character of the list is ~, the effect is inverted: all system calls except the listed system calls will be logged. This feature makes use of the Secure Computing Mode 2 interfaces of the kernel ('seccomp filtering') and is useful for auditing or setting up a minimal sandboxing environment. This option may be specified more than once, in which case the filter masks are merged. If the empty string is assigned, the filter is reset, all prior assignments will have no effect. This does not affect commands prefixed with +. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
906
|
+
readonly SystemCallLog?: string | readonly string[];
|
|
907
|
+
/** Configure the size of the TTY specified with TTYPath=. If unset or set to the empty string, it is attempted to retrieve the dimensions of the terminal screen via ANSI sequences, and if that fails the kernel defaults (typically 80x24) are used. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
908
|
+
readonly TTYColumns?: number;
|
|
909
|
+
/** Sets the terminal device node to use if standard input, output, or error are connected to a TTY (see above). Defaults to /dev/console. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
910
|
+
readonly TTYPath?: string;
|
|
911
|
+
/** Reset the terminal device specified with TTYPath= before and after execution. This does not erase the screen (see TTYVTDisallocate= below for that). Defaults to no. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
912
|
+
readonly TTYReset?: boolean;
|
|
913
|
+
/** Configure the size of the TTY specified with TTYPath=. If unset or set to the empty string, it is attempted to retrieve the dimensions of the terminal screen via ANSI sequences, and if that fails the kernel defaults (typically 80x24) are used. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
914
|
+
readonly TTYRows?: number;
|
|
915
|
+
/** Disconnect all clients which have opened the terminal device specified with TTYPath= before and after execution. Defaults to no. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
916
|
+
readonly TTYVHangup?: boolean;
|
|
917
|
+
/** If the terminal device specified with TTYPath= is a virtual console terminal, try to deallocate the TTY before and after execution. This ensures that the screen and scrollback buffer is cleared. If the terminal device is of any other type of TTY an attempt is made to clear the screen via ANSI sequences. Defaults to no. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
918
|
+
readonly TTYVTDisallocate?: boolean;
|
|
919
|
+
/** This setting controls the pids controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
920
|
+
readonly TasksAccounting?: boolean;
|
|
921
|
+
/** This setting controls the pids controller in the unified hierarchy. Source: systemd v260.1, `systemd.resource-control(5)`. */
|
|
922
|
+
readonly TasksMax?: number | string;
|
|
923
|
+
/** Takes a space-separated list of mount points for temporary file systems (tmpfs). If set, a new file system namespace is set up for executed processes, and a temporary file system is mounted on each mount point. This option may be specified more than once, in which case temporary file systems are mounted on all listed mount points. If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect. Each mount point may optionally be suffixed with a colon (:) and mount options such as size=10% or ro. By default, each temporary file system is mounted with nodev,strictatime,mode=0755. These can be disabled by explicitly specifying the corresponding mount options, e.g., dev or nostrictatime. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
924
|
+
readonly TemporaryFileSystem?: string | readonly string[];
|
|
925
|
+
/** This option configures the time to wait for the service to terminate when it was aborted due to a watchdog timeout (see WatchdogSec=). If the service has a short TimeoutStopSec= this option can be used to give the system more time to write a core dump of the service. Upon expiration the service will be forcibly terminated by SIGKILL (see KillMode= in systemd.kill5). The core file will be truncated in this case. Use TimeoutAbortSec= to set a sensible timeout for the core dumping per service that is large enough to write all expected data while also being short enough to handle the service failure in due time. Source: systemd v260.1, `systemd.service(5)`. */
|
|
926
|
+
readonly TimeoutAbortSec?: number | string;
|
|
927
|
+
/** A shorthand for configuring both TimeoutStartSec= and TimeoutStopSec= to the specified value. Source: systemd v260.1, `systemd.service(5)`. */
|
|
928
|
+
readonly TimeoutSec?: number | string;
|
|
929
|
+
/** Configures a timeout on the clean-up operation requested through systemctl clean …, see systemctl1 for details. Takes the usual time values and defaults to infinity, i.e. by default no timeout is applied. If a timeout is configured the clean operation will be aborted forcibly when the timeout is reached, potentially leaving resources on disk. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
930
|
+
readonly TimeoutCleanSec?: number | string;
|
|
931
|
+
/** These options configure the action that is taken in case a daemon service does not signal start-up within its configured TimeoutStartSec=, respectively if it does not stop within TimeoutStopSec=. Takes one of terminate, abort and kill. Both options default to terminate. Source: systemd v260.1, `systemd.service(5)`. */
|
|
932
|
+
readonly TimeoutStartFailureMode?: TimeoutFailureModeDirectiveValue;
|
|
933
|
+
/** Configures the time to wait for start-up. If a daemon service does not signal start-up completion within the configured time, the service will be considered failed and will be shut down again. The precise action depends on the TimeoutStartFailureMode= option. Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass infinity to disable the timeout logic. Defaults to DefaultTimeoutStartSec= set in the manager, except when Type=oneshot is used, in which case the timeout is disabled by default (see systemd-system.conf(5)). Source: systemd v260.1, `systemd.service(5)`. */
|
|
934
|
+
readonly TimeoutStartSec?: number | string;
|
|
935
|
+
/** These options configure the action that is taken in case a daemon service does not signal start-up within its configured TimeoutStartSec=, respectively if it does not stop within TimeoutStopSec=. Takes one of terminate, abort and kill. Both options default to terminate. Source: systemd v260.1, `systemd.service(5)`. */
|
|
936
|
+
readonly TimeoutStopFailureMode?: TimeoutFailureModeDirectiveValue;
|
|
937
|
+
/** This option serves two purposes. First, it configures the time to wait for each ExecStop= command. If any of them times out, subsequent ExecStop= commands are skipped and the service will be terminated by SIGTERM. If no ExecStop= commands are specified, the service gets the SIGTERM immediately. This default behavior can be changed by the TimeoutStopFailureMode= option. Second, it configures the time to wait for the service itself to stop. If it does not terminate in the specified time, it will be forcibly terminated by SIGKILL (see KillMode= in systemd.kill5). Takes a unit-less value in seconds, or a time span value such as "5min 20s". Pass infinity to disable the timeout logic. Defaults to DefaultTimeoutStopSec= from the manager configuration file (see systemd-system.conf(5)). Source: systemd v260.1, `systemd.service(5)`. */
|
|
938
|
+
readonly TimeoutStopSec?: number | string;
|
|
939
|
+
/** Sets the timer slack in nanoseconds for the executed processes. The timer slack controls the accuracy of wake-ups triggered by 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. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
940
|
+
readonly TimerSlackNSec?: number | string;
|
|
941
|
+
/** Controls the file mode creation mask. Takes an access mode in octal notation. See umask2 for details. Defaults to 0022 for system units. For user units the default value is inherited from the per-user service manager (whose default is in turn inherited from the system service manager, and thus typically also is 0022 — unless overridden by a PAM module). In order to change the per-user mask for all user services, consider setting the UMask= setting of the user's user@.service system service instance. The per-user umask may also be set via the umask field of a user's JSON User Record (for users managed by systemd-homed.service8 this field may be controlled via homectl --umask=). It may also be set via a PAM module, such as pam_umask8. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
942
|
+
readonly UMask?: string;
|
|
943
|
+
/** Configure the location of a file containing USB FunctionFS descriptors, for implementation of USB gadget functions. This is used only in conjunction with a socket unit with ListenUSBFunction= configured. The contents of this file are written to the ep0 file after it is opened. Source: systemd v260.1, `systemd.service(5)`. */
|
|
944
|
+
readonly USBFunctionDescriptors?: string;
|
|
945
|
+
/** Configure the location of a file containing USB FunctionFS strings. Behavior is similar to USBFunctionDescriptors= above. Source: systemd v260.1, `systemd.service(5)`. */
|
|
946
|
+
readonly USBFunctionStrings?: string;
|
|
947
|
+
/** Explicitly unset environment variable assignments that would normally be passed from the service manager to invoked processes of this unit. Takes a space-separated list of variable names or variable assignments. This option may be specified more than once, in which case all listed variables/assignments will be unset. If the empty string is assigned to this option, the list of environment variables/assignments to unset is reset. If a variable assignment is specified (that is: a variable name, followed by =, followed by its value), then any environment variable matching this precise assignment is removed. If a variable name is specified (that is a variable name without any following = or value), then any assignment matching the variable name, regardless of its value is removed. Note that the effect of UnsetEnvironment= is applied as final step when the environment list passed to executed processes is compiled. That means it may undo assignments from any configuration source, including assignments made through Environment= or EnvironmentFile=, inherited from the system manager's global set of environment variables, inherited via PassEnvironment=, set by the service manager itself (such as $NOTIFY_SOCKET and such), or set by a PAM module (in case PAMName= is used). Source: systemd v260.1, `systemd.exec(5)`. */
|
|
948
|
+
readonly UnsetEnvironment?: string | readonly string[];
|
|
949
|
+
/** Set the UNIX user or group that the processes are executed as, respectively. Takes a single user or group name, or a numeric ID as argument. For system services (services run by the system service manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of systemd --user), the default is root, but this directive may be used to specify a different identity. For user services of any other user, switching user identity is not permitted, hence the only valid setting is the same user the user's service manager is running as. If no group is set, the default group of the user is used. This setting does not affect commands whose command line is prefixed with +. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
950
|
+
readonly User?: string;
|
|
951
|
+
/** Takes an absolute file system path referring to a Linux user namespace pseudo-file (i.e. a file like /proc/$PID/ns/user or a bind mount or symlink to one). When set the invoked processes are added to the user namespace referenced by that path. The path has to point to a valid namespace file at the moment the processes are forked off. If this option is used PrivateUsers= has no effect. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
952
|
+
readonly UserNamespacePath?: string;
|
|
953
|
+
/** Takes a four character identifier string for an utmp5 and wtmp entry for this service. This should only be set for services such as getty implementations (such as agetty8) where utmp/wtmp entries must be created and cleared before and after execution, or for services that shall be executed as if they were run by a getty process (see below). If the configured string is longer than four characters, it is truncated and the terminal four characters are used. This setting interprets %I style string replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this service. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
954
|
+
readonly UtmpIdentifier?: string;
|
|
955
|
+
/** Takes one of init, login or user. If UtmpIdentifier= is set, controls which type of utmp5/wtmp entries for this service are generated. This setting has no effect unless UtmpIdentifier= is set too. If init is set, only an INIT_PROCESS entry is generated and the invoked process must implement a getty-compatible utmp/wtmp logic. If login is set, first an INIT_PROCESS entry, followed by a LOGIN_PROCESS entry is generated. In this case, the invoked process must implement a login1-compatible utmp/wtmp logic. If user is set, first an INIT_PROCESS entry, then a LOGIN_PROCESS entry and finally a USER_PROCESS entry is generated. In this case, the invoked process may be any process that is suitable to be run as session leader. Defaults to init. Source: systemd v260.1, `systemd.exec(5)`. */
|
|
956
|
+
readonly UtmpMode?: UtmpModeDirectiveValue;
|
|
957
|
+
/** Configures the mechanism via which the service notifies the manager that the service start-up has finished. One of simple, exec, forking, oneshot, dbus, notify, notify-reload, or idle:. Source: systemd v260.1, `systemd.service(5)`. */
|
|
958
|
+
readonly Type?: ServiceTypeDirectiveValue;
|
|
959
|
+
/** Configures the watchdog timeout for a service. The watchdog is activated when the start-up is completed. The service must call sd_notify3 regularly with WATCHDOG=1 (i.e. the "keep-alive ping"). If the time between two such calls is larger than the configured time, then the service is placed in a failed state and it will be terminated with SIGABRT (or the signal specified by WatchdogSignal=). By setting Restart= to on-failure, on-watchdog, on-abnormal or always, the service will be automatically restarted. The time configured here will be passed to the executed service process in the WATCHDOG_USEC= environment variable. This allows daemons to automatically enable the keep-alive pinging logic if watchdog support is enabled for the service. If this option is used, NotifyAccess= (see below) should be set to open access to the notification socket provided by systemd. If NotifyAccess= is not set, it will be implicitly set to main. Defaults to 0, which disables this feature. The service can check whether the service manager expects watchdog keep-alive notifications. See sd_watchdog_enabled3 for details. sd_event_set_watchdog3 may be used to enable automatic watchdog notification support. Source: systemd v260.1, `systemd.service(5)`. */
|
|
960
|
+
readonly WatchdogSec?: number | string;
|
|
961
|
+
/** Specifies which signal to use to terminate the service when the watchdog timeout expires (enabled through WatchdogSec=). Defaults to SIGABRT. Source: systemd v260.1, `systemd.kill(5)`. */
|
|
962
|
+
readonly WatchdogSignal?: NodeJS.Signals | number;
|
|
963
|
+
/** Takes a directory path relative to the service's root directory specified by RootDirectory=, or the special value ~. Sets the working directory for executed processes. If set to ~, the home directory of the user specified in User= is used. If not set, defaults to the root directory when systemd is running as a system instance and the respective user's home directory if run as user. If the setting is prefixed with the - character, a missing working directory is not considered fatal. If RootDirectory=/RootImage= is not set, then WorkingDirectory= is relative to the root of the system running the service manager. Note that setting this parameter might result in additional dependencies to be added to the unit (see above). Source: systemd v260.1, `systemd.exec(5)`. */
|
|
964
|
+
readonly WorkingDirectory?: string;
|
|
545
965
|
}
|
|
546
966
|
/**
|
|
547
967
|
* @deprecated Use one of the specific section interfaces instead:
|