2 <!DOCTYPE refentry PUBLIC
"-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd" [
4 <!ENTITY % entities SYSTEM
"custom-entities.ent" >
7 <!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
9 <refentry id=
"systemd-system.conf"
10 xmlns:
xi=
"http://www.w3.org/2001/XInclude">
12 <title>systemd-system.conf
</title>
13 <productname>systemd
</productname>
17 <refentrytitle>systemd-system.conf
</refentrytitle>
18 <manvolnum>5</manvolnum>
22 <refname>systemd-system.conf
</refname>
23 <refname>system.conf.d
</refname>
24 <refname>systemd-user.conf
</refname>
25 <refname>user.conf.d
</refname>
26 <refpurpose>System and session service manager configuration files
</refpurpose>
30 <para><filename>/etc/systemd/system.conf
</filename>,
31 <filename>/etc/systemd/system.conf.d/*.conf
</filename>,
32 <filename>/run/systemd/system.conf.d/*.conf
</filename>,
33 <filename>/usr/lib/systemd/system.conf.d/*.conf
</filename></para>
35 <para><filename>~/.config/systemd/user.conf
</filename>,
36 <filename>/etc/systemd/user.conf
</filename>,
37 <filename>/etc/systemd/user.conf.d/*.conf
</filename>,
38 <filename>/run/systemd/user.conf.d/*.conf
</filename>,
39 <filename>/usr/lib/systemd/user.conf.d/*.conf
</filename></para>
43 <title>Description
</title>
45 <para>When run as a system instance,
<command>systemd
</command> interprets the configuration file
46 <filename>system.conf
</filename> and the files in
<filename>system.conf.d
</filename> directories; when
47 run as a user instance, it interprets the configuration file
<filename>user.conf
</filename> (either in
48 the home directory of the user, or if not found, under
<filename>/etc/systemd/
</filename>) and the files
49 in
<filename>user.conf.d
</filename> directories. These configuration files contain a few settings
50 controlling basic manager operations.
</para>
53 <citerefentry><refentrytitle>systemd.syntax
</refentrytitle><manvolnum>7</manvolnum></citerefentry> for a
54 general description of the syntax.
</para>
57 <xi:include href=
"standard-conf.xml" xpointer=
"main-conf" />
60 <title>Options
</title>
62 <para>All options are configured in the
63 [Manager] section:
</para>
65 <variablelist class='config-directives'
>
68 <term><varname>LogColor=
</varname></term>
69 <term><varname>LogLevel=
</varname></term>
70 <term><varname>LogLocation=
</varname></term>
71 <term><varname>LogTarget=
</varname></term>
72 <term><varname>LogTime=
</varname></term>
73 <term><varname>DumpCore=yes
</varname></term>
74 <term><varname>CrashChangeVT=no
</varname></term>
75 <term><varname>CrashShell=no
</varname></term>
76 <term><varname>CrashReboot=no
</varname></term>
77 <term><varname>ShowStatus=yes
</varname></term>
78 <term><varname>DefaultStandardOutput=journal
</varname></term>
79 <term><varname>DefaultStandardError=inherit
</varname></term>
81 <listitem><para>Configures various parameters of basic manager operation. These options may be overridden by
82 the respective process and kernel command line arguments. See
83 <citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
84 details.
</para></listitem>
88 <term><varname>CtrlAltDelBurstAction=
</varname></term>
90 <listitem><para>Defines what action will be performed
91 if user presses Ctrl-Alt-Delete more than
7 times in
2s.
92 Can be set to
<literal>reboot-force
</literal>,
<literal>poweroff-force
</literal>,
93 <literal>reboot-immediate
</literal>,
<literal>poweroff-immediate
</literal>
94 or disabled with
<literal>none
</literal>. Defaults to
95 <literal>reboot-force
</literal>.
100 <term><varname>CPUAffinity=
</varname></term>
102 <listitem><para>Configures the CPU affinity for the service manager as well as the default CPU
103 affinity for all forked off processes. Takes a list of CPU indices or ranges separated by either
104 whitespace or commas. CPU ranges are specified by the lower and upper CPU indices separated by a
105 dash. This option may be specified more than once, in which case the specified CPU affinity masks are
106 merged. If the empty string is assigned, the mask is reset, all assignments prior to this will have
107 no effect. Individual services may override the CPU affinity for their processes with the
108 <varname>CPUAffinity=
</varname> setting in unit files, see
109 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
113 <term><varname>NUMAPolicy=
</varname></term>
115 <listitem><para>Configures the NUMA memory policy for the service manager and the default NUMA memory policy
116 for all forked off processes. Individual services may override the default policy with the
117 <varname>NUMAPolicy=
</varname> setting in unit files, see
118 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
122 <term><varname>NUMAMask=
</varname></term>
124 <listitem><para>Configures the NUMA node mask that will be associated with the selected NUMA policy. Note that
125 <option>default
</option> and
<option>local
</option> NUMA policies don't require explicit NUMA node mask and
126 value of the option can be empty. Similarly to
<varname>NUMAPolicy=
</varname>, value can be overridden
127 by individual services in unit files, see
128 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
132 <term><varname>RuntimeWatchdogSec=
</varname></term>
133 <term><varname>RebootWatchdogSec=
</varname></term>
134 <term><varname>KExecWatchdogSec=
</varname></term>
136 <listitem><para>Configure the hardware watchdog at runtime and at reboot. Takes a timeout value in
137 seconds (or in other time units if suffixed with
<literal>ms
</literal>,
<literal>min
</literal>,
138 <literal>h
</literal>,
<literal>d
</literal>,
<literal>w
</literal>), or the special strings
139 <literal>off
</literal> or
<literal>default
</literal>. If set to
<literal>off
</literal>
140 (alternatively:
<literal>0</literal>) the watchdog logic is disabled: no watchdog device is opened,
141 configured, or pinged. If set to the special string
<literal>default
</literal> the watchdog is opened
142 and pinged in regular intervals, but the timeout is not changed from the default. If set to any other
143 time value the watchdog timeout is configured to the specified value (or a value close to it,
144 depending on hardware capabilities).
</para>
146 <para>If
<varname>RuntimeWatchdogSec=
</varname> is set to a non-zero value, the watchdog hardware
147 (
<filename>/dev/watchdog0
</filename> or the path specified with
<varname>WatchdogDevice=
</varname> or
148 the kernel option
<varname>systemd.watchdog-device=
</varname>) will be programmed to automatically
149 reboot the system if it is not contacted within the specified timeout interval. The system manager
150 will ensure to contact it at least once in half the specified timeout interval. This feature requires
151 a hardware watchdog device to be present, as it is commonly the case in embedded and server
152 systems. Not all hardware watchdogs allow configuration of all possible reboot timeout values, in
153 which case the closest available timeout is picked.
</para>
155 <para><varname>RebootWatchdogSec=
</varname> may be used to configure the hardware watchdog when the
156 system is asked to reboot. It works as a safety net to ensure that the reboot takes place even if a
157 clean reboot attempt times out. Note that the
<varname>RebootWatchdogSec=
</varname> timeout applies
158 only to the second phase of the reboot, i.e. after all regular services are already terminated, and
159 after the system and service manager process (PID
1) got replaced by the
160 <filename>systemd-shutdown
</filename> binary, see system
161 <citerefentry><refentrytitle>bootup
</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
162 details. During the first phase of the shutdown operation the system and service manager remains
163 running and hence
<varname>RuntimeWatchdogSec=
</varname> is still honoured. In order to define a
164 timeout on this first phase of system shutdown, configure
<varname>JobTimeoutSec=
</varname> and
165 <varname>JobTimeoutAction=
</varname> in the [Unit] section of the
166 <filename>shutdown.target
</filename> unit. By default
<varname>RuntimeWatchdogSec=
</varname> defaults
167 to
0 (off), and
<varname>RebootWatchdogSec=
</varname> to
10min.
</para>
169 <para><varname>KExecWatchdogSec=
</varname> may be used to additionally enable the watchdog when kexec
170 is being executed rather than when rebooting. Note that if the kernel does not reset the watchdog on
171 kexec (depending on the specific hardware and/or driver), in this case the watchdog might not get
172 disabled after kexec succeeds and thus the system might get rebooted, unless
173 <varname>RuntimeWatchdogSec=
</varname> is also enabled at the same time. For this reason it is
174 recommended to enable
<varname>KExecWatchdogSec=
</varname> only if
175 <varname>RuntimeWatchdogSec=
</varname> is also enabled.
</para>
177 <para>These settings have no effect if a hardware watchdog is not available.
</para></listitem>
181 <term><varname>RuntimeWatchdogPreSec=
</varname></term>
183 <listitem><para>Configure the hardware watchdog device pre-timeout value.
184 Takes a timeout value in seconds (or in other time units similar to
185 <varname>RuntimeWatchdogSec=
</varname>). A watchdog pre-timeout is a
186 notification generated by the watchdog before the watchdog reset might
187 occur in the event the watchdog has not been serviced. This notification
188 is handled by the kernel and can be configured to take an action (i.e.
189 generate a kernel panic) using
<varname>RuntimeWatchdogPreGovernor=
</varname>.
190 Not all watchdog hardware or drivers support generating a pre-timeout and
191 depending on the state of the system, the kernel may be unable to take the
192 configured action before the watchdog reboot. The watchdog will be configured
193 to generate the pre-timeout event at the amount of time specified by
194 <varname>RuntimeWatchdogPreSec=
</varname> before the runtime watchdog timeout
195 (set by
<varname>RuntimeWatchdogSec=
</varname>). For example, if the we have
196 <varname>RuntimeWatchdogSec=
30</varname> and
197 <varname>RuntimeWatchdogPreSec=
10</varname>, then the pre-timeout event
198 will occur if the watchdog has not pinged for
20s (
10s before the
199 watchdog would fire). By default,
<varname>RuntimeWatchdogPreSec=
</varname>
200 defaults to
0 (off). The value set for
<varname>RuntimeWatchdogPreSec=
</varname>
201 must be smaller than the timeout value for
<varname>RuntimeWatchdogSec=
</varname>.
202 This setting has no effect if a hardware watchdog is not available or the
203 hardware watchdog does not support a pre-timeout and will be ignored by the
204 kernel if the setting is greater than the actual watchdog timeout.
</para></listitem>
208 <term><varname>RuntimeWatchdogPreGovernor=
</varname></term>
210 <listitem><para>Configure the action taken by the hardware watchdog device
211 when the pre-timeout expires. The default action for the pre-timeout event
212 depends on the kernel configuration, but it is usually to log a kernel
213 message. For a list of valid actions available for a given watchdog device,
214 check the content of the
215 <filename>/sys/class/watchdog/watchdog
<replaceable>X
</replaceable>/pretimeout_available_governors
</filename>
216 file. Typically, available governor types are
<varname>noop
</varname> and
<varname>panic
</varname>.
217 Availability, names and functionality might vary depending on the specific device driver
218 in use. If the
<filename>pretimeout_available_governors
</filename> sysfs file is empty,
219 the governor might be built as a kernel module and might need to be manually loaded
220 (e.g.
<varname>pretimeout_noop.ko
</varname>), or the watchdog device might not support
221 pre-timeouts.
</para></listitem>
225 <term><varname>WatchdogDevice=
</varname></term>
227 <listitem><para>Configure the hardware watchdog device that the
228 runtime and shutdown watchdog timers will open and use. Defaults
229 to
<filename>/dev/watchdog0
</filename>. This setting has no
230 effect if a hardware watchdog is not available.
</para></listitem>
234 <term><varname>CapabilityBoundingSet=
</varname></term>
236 <listitem><para>Controls which capabilities to include in the
237 capability bounding set for PID
1 and its children. See
238 <citerefentry project='man-pages'
><refentrytitle>capabilities
</refentrytitle><manvolnum>7</manvolnum></citerefentry>
239 for details. Takes a whitespace-separated list of capability
241 <citerefentry project='mankier'
><refentrytitle>cap_from_name
</refentrytitle><manvolnum>3</manvolnum></citerefentry>.
242 Capabilities listed will be included in the bounding set, all
243 others are removed. If the list of capabilities is prefixed
244 with ~, all but the listed capabilities will be included, the
245 effect of the assignment inverted. Note that this option also
246 affects the respective capabilities in the effective,
247 permitted and inheritable capability sets. The capability
248 bounding set may also be individually configured for units
249 using the
<varname>CapabilityBoundingSet=
</varname> directive
250 for units, but note that capabilities dropped for PID
1 cannot
251 be regained in individual units, they are lost for
252 good.
</para></listitem>
256 <term><varname>NoNewPrivileges=
</varname></term>
258 <listitem><para>Takes a boolean argument. If true, ensures that PID
1
259 and all its children can never gain new privileges through
260 <citerefentry project='man-pages'
><refentrytitle>execve
</refentrytitle><manvolnum>2</manvolnum></citerefentry>
261 (e.g. via setuid or setgid bits, or filesystem capabilities).
262 Defaults to false. General purpose distributions commonly rely
263 on executables with setuid or setgid bits and will thus not
264 function properly with this option enabled. Individual units
265 cannot disable this option.
266 Also see
<ulink url=
"https://docs.kernel.org/userspace-api/no_new_privs.html">No New Privileges Flag
</ulink>.
271 <term><varname>SystemCallArchitectures=
</varname></term>
273 <listitem><para>Takes a space-separated list of architecture
274 identifiers. Selects from which architectures system calls may
275 be invoked on this system. This may be used as an effective
276 way to disable invocation of non-native binaries system-wide,
277 for example to prohibit execution of
32-bit x86 binaries on
278 64-bit x86-
64 systems. This option operates system-wide, and
280 <varname>SystemCallArchitectures=
</varname> setting of unit
282 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
283 for details. This setting defaults to the empty list, in which
284 case no filtering of system calls based on architecture is
285 applied. Known architecture identifiers are
286 <literal>x86
</literal>,
<literal>x86-
64</literal>,
287 <literal>x32
</literal>,
<literal>arm
</literal> and the special
288 identifier
<literal>native
</literal>. The latter implicitly
289 maps to the native architecture of the system (or more
290 specifically, the architecture the system manager was compiled
291 for). Set this setting to
<literal>native
</literal> to
292 prohibit execution of any non-native binaries. When a binary
293 executes a system call of an architecture that is not listed
294 in this setting, it will be immediately terminated with the
295 SIGSYS signal.
</para></listitem>
299 <term><varname>TimerSlackNSec=
</varname></term>
301 <listitem><para>Sets the timer slack in nanoseconds for PID
1,
302 which is inherited by all executed processes, unless
303 overridden individually, for example with the
304 <varname>TimerSlackNSec=
</varname> setting in service units
306 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
307 The timer slack controls the accuracy of wake-ups triggered by
309 <citerefentry><refentrytitle>prctl
</refentrytitle><manvolnum>2</manvolnum></citerefentry>
310 for more information. Note that in contrast to most other time
311 span definitions this parameter takes an integer value in
312 nano-seconds if no unit is specified. The usual time units are
313 understood too.
</para></listitem>
317 <term><varname>StatusUnitFormat=
</varname></term>
319 <listitem><para>Takes
<option>name
</option>,
<option>description
</option> or
320 <option>combined
</option> as the value. If
<option>name
</option>, the system manager will use unit
321 names in status messages (e.g.
<literal>systemd-journald.service
</literal>), instead of the longer
322 and more informative descriptions set with
<varname>Description=
</varname> (e.g.
<literal>Journal
323 Logging Service
</literal>). If
<option>combined
</option>, the system manager will use both unit names
324 and descriptions in status messages (e.g.
<literal>systemd-journald.service - Journal Logging
325 Service
</literal>).
</para>
328 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
329 details about unit names and
<varname>Description=
</varname>.
</para></listitem>
333 <term><varname>DefaultTimerAccuracySec=
</varname></term>
335 <listitem><para>Sets the default accuracy of timer units. This
336 controls the global default for the
337 <varname>AccuracySec=
</varname> setting of timer units, see
338 <citerefentry><refentrytitle>systemd.timer
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
339 for details.
<varname>AccuracySec=
</varname> set in individual
340 units override the global default for the specific unit.
341 Defaults to
1min. Note that the accuracy of timer units is
342 also affected by the configured timer slack for PID
1, see
343 <varname>TimerSlackNSec=
</varname> above.
</para></listitem>
347 <term><varname>DefaultTimeoutStartSec=
</varname></term>
348 <term><varname>DefaultTimeoutStopSec=
</varname></term>
349 <term><varname>DefaultTimeoutAbortSec=
</varname></term>
350 <term><varname>DefaultRestartSec=
</varname></term>
352 <listitem><para>Configures the default timeouts for starting,
353 stopping and aborting of units, as well as the default time to sleep
354 between automatic restarts of units, as configured per-unit in
355 <varname>TimeoutStartSec=
</varname>,
356 <varname>TimeoutStopSec=
</varname>,
357 <varname>TimeoutAbortSec=
</varname> and
358 <varname>RestartSec=
</varname> (for services, see
359 <citerefentry><refentrytitle>systemd.service
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
360 for details on the per-unit settings). Disabled by default, when
361 service with
<varname>Type=oneshot
</varname> is used.
362 For non-service units,
363 <varname>DefaultTimeoutStartSec=
</varname> sets the default
364 <varname>TimeoutSec=
</varname>
365 value.
<varname>DefaultTimeoutStartSec=
</varname> and
366 <varname>DefaultTimeoutStopSec=
</varname> default to
367 90s.
<varname>DefaultTimeoutAbortSec=
</varname> is not set by default
368 so that all units fall back to
<varname>TimeoutStopSec=
</varname>.
369 <varname>DefaultRestartSec=
</varname> defaults to
370 100ms.
</para></listitem>
374 <term><varname>DefaultDeviceTimeoutSec=
</varname></term>
376 <listitem><para>Configures the default timeout for waiting for devices. It can be changed per
377 device via the
<varname>x-systemd.device-timeout=
</varname> option in
<filename>/etc/fstab
</filename>
378 and
<filename>/etc/crypttab
</filename> (see
379 <citerefentry><refentrytitle>systemd.mount
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
380 <citerefentry><refentrytitle>crypttab
</refentrytitle><manvolnum>5</manvolnum></citerefentry>).
381 Defaults to
90s.
</para></listitem>
385 <term><varname>DefaultStartLimitIntervalSec=
</varname></term>
386 <term><varname>DefaultStartLimitBurst=
</varname></term>
388 <listitem><para>Configure the default unit start rate
389 limiting, as configured per-service by
390 <varname>StartLimitIntervalSec=
</varname> and
391 <varname>StartLimitBurst=
</varname>. See
392 <citerefentry><refentrytitle>systemd.service
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
393 for details on the per-service settings.
394 <varname>DefaultStartLimitIntervalSec=
</varname> defaults to
395 10s.
<varname>DefaultStartLimitBurst=
</varname> defaults to
400 <term><varname>DefaultEnvironment=
</varname></term>
402 <listitem><para>Configures environment variables passed to all executed processes. Takes a
403 space-separated list of variable assignments. See
<citerefentry
404 project='man-pages'
><refentrytitle>environ
</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
405 details about environment variables.
</para>
407 <para>Simple
<literal>%
</literal>-specifier expansion is supported, see below for a list of supported
412 <programlisting>DefaultEnvironment=
"VAR1=word1 word2" VAR2=word3
"VAR3=word 5 6"</programlisting>
415 <literal>VAR1
</literal>,
416 <literal>VAR2
</literal>,
417 <literal>VAR3
</literal>.
</para></listitem>
421 <term><varname>ManagerEnvironment=
</varname></term>
423 <listitem><para>Takes the same arguments as
<varname>DefaultEnvironment=
</varname>, see above. Sets
424 environment variables just for the manager process itself. In contrast to user managers, these variables
425 are not inherited by processes spawned by the system manager, use
<varname>DefaultEnvironment=
</varname>
426 for that. Note that these variables are merged into the existing environment block. In particular, in
427 case of the system manager, this includes variables set by the kernel based on the kernel command line.
</para>
429 <para>Setting environment variables for the manager process may be useful to modify its behaviour.
430 See
<ulink url=
"https://systemd.io/ENVIRONMENT">ENVIRONMENT
</ulink> for a descriptions of some
431 variables understood by
<command>systemd
</command>.
</para>
433 <para>Simple
<literal>%
</literal>-specifier expansion is supported, see below for a list of supported
439 <term><varname>DefaultCPUAccounting=
</varname></term>
440 <term><varname>DefaultMemoryAccounting=
</varname></term>
441 <term><varname>DefaultTasksAccounting=
</varname></term>
442 <term><varname>DefaultIOAccounting=
</varname></term>
443 <term><varname>DefaultIPAccounting=
</varname></term>
445 <listitem><para>Configure the default resource accounting settings, as configured per-unit by
446 <varname>CPUAccounting=
</varname>,
<varname>MemoryAccounting=
</varname>,
447 <varname>TasksAccounting=
</varname>,
<varname>IOAccounting=
</varname> and
448 <varname>IPAccounting=
</varname>. See
449 <citerefentry><refentrytitle>systemd.resource-control
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
450 for details on the per-unit settings.
<varname>DefaultTasksAccounting=
</varname> defaults to yes,
451 <varname>DefaultMemoryAccounting=
</varname> to
452 &MEMORY_ACCOUNTING_DEFAULT;.
<varname>DefaultCPUAccounting=
</varname> defaults to yes if enabling CPU
453 accounting doesn't require the CPU controller to be enabled (Linux
4.15+ using the unified hierarchy
454 for resource control), otherwise it defaults to no. The other three settings default to
455 no.
</para></listitem>
459 <term><varname>DefaultTasksMax=
</varname></term>
461 <listitem><para>Configure the default value for the per-unit
<varname>TasksMax=
</varname> setting. See
462 <citerefentry><refentrytitle>systemd.resource-control
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
463 for details. This setting applies to all unit types that support resource control settings, with the exception
464 of slice units. Defaults to
15% of the minimum of
<varname>kernel.pid_max=
</varname>,
<varname>kernel.threads-max=
</varname>
465 and root cgroup
<varname>pids.max
</varname>.
466 Kernel has a default value for
<varname>kernel.pid_max=
</varname> and an algorithm of counting in case of more than
32 cores.
467 For example with the default
<varname>kernel.pid_max=
</varname>,
<varname>DefaultTasksMax=
</varname> defaults to
4915,
468 but might be greater in other systems or smaller in OS containers.
</para></listitem>
472 <term><varname>DefaultLimitCPU=
</varname></term>
473 <term><varname>DefaultLimitFSIZE=
</varname></term>
474 <term><varname>DefaultLimitDATA=
</varname></term>
475 <term><varname>DefaultLimitSTACK=
</varname></term>
476 <term><varname>DefaultLimitCORE=
</varname></term>
477 <term><varname>DefaultLimitRSS=
</varname></term>
478 <term><varname>DefaultLimitNOFILE=
</varname></term>
479 <term><varname>DefaultLimitAS=
</varname></term>
480 <term><varname>DefaultLimitNPROC=
</varname></term>
481 <term><varname>DefaultLimitMEMLOCK=
</varname></term>
482 <term><varname>DefaultLimitLOCKS=
</varname></term>
483 <term><varname>DefaultLimitSIGPENDING=
</varname></term>
484 <term><varname>DefaultLimitMSGQUEUE=
</varname></term>
485 <term><varname>DefaultLimitNICE=
</varname></term>
486 <term><varname>DefaultLimitRTPRIO=
</varname></term>
487 <term><varname>DefaultLimitRTTIME=
</varname></term>
489 <listitem><para>These settings control various default resource limits for processes executed by
491 <citerefentry><refentrytitle>setrlimit
</refentrytitle><manvolnum>2</manvolnum></citerefentry> for
492 details. These settings may be overridden in individual units using the corresponding
493 <varname>LimitXXX=
</varname> directives and they accept the same parameter syntax,
494 see
<citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
495 for details. Note that these resource limits are only defaults
496 for units, they are not applied to the service manager process (i.e. PID
1) itself.
</para>
498 <para>Most of these settings are unset, which means the resource limits are inherited from the kernel or, if
499 invoked in a container, from the container manager. However, the following have defaults:
</para>
501 <listitem><para><varname>DefaultLimitNOFILE=
</varname> defaults to
1024:
&HIGH_RLIMIT_NOFILE;.
504 <listitem><para><varname>DefaultLimitMEMLOCK=
</varname> defaults to
8M.
</para></listitem>
506 <listitem><para><varname>DefaultLimitCORE=
</varname> does not have a default but it is worth mentioning that
507 <varname>RLIMIT_CORE
</varname> is set to
<literal>infinity
</literal> by PID
1 which is inherited by its
508 children.
</para></listitem>
511 <para>Note that the service manager internally in PID
1 bumps
<varname>RLIMIT_NOFILE
</varname> and
512 <varname>RLIMIT_MEMLOCK
</varname> to higher values, however the limit is reverted to the mentioned
513 defaults for all child processes forked off.
</para>
518 <term><varname>DefaultOOMPolicy=
</varname></term>
520 <listitem><para>Configure the default policy for reacting to processes being killed by the Linux
521 Out-Of-Memory (OOM) killer or
<command>systemd-oomd
</command>. This may be used to pick a global default for the per-unit
522 <varname>OOMPolicy=
</varname> setting. See
523 <citerefentry><refentrytitle>systemd.service
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
524 for details. Note that this default is not used for services that have
<varname>Delegate=
</varname>
525 turned on.
</para></listitem>
529 <term><varname>DefaultOOMScoreAdjust=
</varname></term>
531 <listitem><para>Configures the default OOM score adjustments of processes run by the service
532 manager. This defaults to unset (meaning the forked off processes inherit the service manager's OOM
533 score adjustment value), except if the service manager is run for an unprivileged user, in which case
534 this defaults to the service manager's OOM adjustment value plus
100 (this makes service processes
535 slightly more likely to be killed under memory pressure than the manager itself). This may be used to
536 pick a global default for the per-unit
<varname>OOMScoreAdjust=
</varname> setting. See
537 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
538 details. Note that this setting has no effect on the OOM score adjustment value of the service
539 manager process itself, it retains the original value set during its invocation.
</para></listitem>
543 <term><varname>DefaultSmackProcessLabel=
</varname></term>
545 <listitem><para>Takes a
<option>SMACK64
</option> security label as the argument. The process executed
546 by a unit will be started under this label if
<varname>SmackProcessLabel=
</varname> is not set in the
547 unit. See
<citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
548 for the details.
</para>
550 <para>If the value is
<literal>/
</literal>, only labels specified with
<varname>SmackProcessLabel=
</varname>
551 are assigned and the compile-time default is ignored.
</para></listitem>
557 <title>Specifiers
</title>
559 <para>Specifiers may be used in the
<varname>DefaultEnvironment=
</varname> and
560 <varname>ManagerEnvironment=
</varname> settings. The following expansions are understood:
</para>
561 <table class='specifiers'
>
562 <title>Specifiers available
</title>
563 <tgroup cols='
3' align='left' colsep='
1' rowsep='
1'
>
564 <colspec colname=
"spec" />
565 <colspec colname=
"mean" />
566 <colspec colname=
"detail" />
569 <entry>Specifier
</entry>
570 <entry>Meaning
</entry>
571 <entry>Details
</entry>
575 <xi:include href=
"standard-specifiers.xml" xpointer=
"a"/>
576 <xi:include href=
"standard-specifiers.xml" xpointer=
"A"/>
577 <xi:include href=
"standard-specifiers.xml" xpointer=
"b"/>
578 <xi:include href=
"standard-specifiers.xml" xpointer=
"B"/>
579 <xi:include href=
"standard-specifiers.xml" xpointer=
"H"/>
580 <xi:include href=
"standard-specifiers.xml" xpointer=
"l"/>
581 <xi:include href=
"standard-specifiers.xml" xpointer=
"m"/>
582 <xi:include href=
"standard-specifiers.xml" xpointer=
"M"/>
583 <xi:include href=
"standard-specifiers.xml" xpointer=
"o"/>
584 <xi:include href=
"standard-specifiers.xml" xpointer=
"v"/>
585 <xi:include href=
"standard-specifiers.xml" xpointer=
"w"/>
586 <xi:include href=
"standard-specifiers.xml" xpointer=
"W"/>
587 <xi:include href=
"standard-specifiers.xml" xpointer=
"T"/>
588 <xi:include href=
"standard-specifiers.xml" xpointer=
"V"/>
589 <xi:include href=
"standard-specifiers.xml" xpointer=
"percent"/>
596 <title>History
</title>
600 <term>systemd
252</term>
601 <listitem><para>Option
<varname>DefaultBlockIOAccounting=
</varname> was deprecated. Please switch
602 to the unified cgroup hierarchy.
</para></listitem>
608 <title>See Also
</title>
610 <citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
611 <citerefentry><refentrytitle>systemd.directives
</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
612 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
613 <citerefentry><refentrytitle>systemd.service
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
614 <citerefentry project='man-pages'
><refentrytitle>environ
</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
615 <citerefentry project='man-pages'
><refentrytitle>capabilities
</refentrytitle><manvolnum>7</manvolnum></citerefentry>