2 <!DOCTYPE refentry PUBLIC
"-//OASIS//DTD DocBook XML V4.5//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
4 <!-- SPDX-License-Identifier: LGPL-2.1+ -->
7 xmlns:
xi=
"http://www.w3.org/2001/XInclude">
10 <title>systemd
</title>
11 <productname>systemd
</productname>
15 <refentrytitle>systemd
</refentrytitle>
16 <manvolnum>1</manvolnum>
20 <refname>systemd
</refname>
21 <refname>init
</refname>
22 <refpurpose>systemd system and service manager
</refpurpose>
27 <command>/usr/lib/systemd/systemd
</command>
28 <arg choice=
"opt" rep=
"repeat">OPTIONS
</arg>
31 <command>init
</command>
32 <arg choice=
"opt" rep=
"repeat">OPTIONS
</arg>
33 <arg choice=
"req">COMMAND
</arg>
38 <title>Description
</title>
40 <para>systemd is a system and service manager for Linux operating systems. When run as first process on
41 boot (as PID
1), it acts as init system that brings up and maintains userspace services. Separate
42 instances are started for logged-in users to start their services.
</para>
44 <para><command>systemd
</command> is usually not invoked directly by the user, but is installed as the
45 <filename>/sbin/init
</filename> symlink and started during early boot. The user manager instances are
46 started automatically through the
47 <citerefentry><refentrytitle>user@.service
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
50 <para>For compatibility with SysV, if the binary is called as
<command>init
</command> and is not the
51 first process on the machine (PID is not
1), it will execute
<command>telinit
</command> and pass all
52 command line arguments unmodified. That means
<command>init
</command> and
<command>telinit
</command> are
53 mostly equivalent when invoked from normal login sessions. See
54 <citerefentry><refentrytitle>telinit
</refentrytitle><manvolnum>8</manvolnum></citerefentry> for more
57 <para>When run as a system instance, systemd interprets the
58 configuration file
<filename>system.conf
</filename> and the files
59 in
<filename>system.conf.d
</filename> directories; when run as a
60 user instance, systemd interprets the configuration file
61 <filename>user.conf
</filename> and the files in
62 <filename>user.conf.d
</filename> directories. See
63 <citerefentry><refentrytitle>systemd-system.conf
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
64 for more information.
</para>
68 <title>Concepts
</title>
70 <para>systemd provides a dependency system between various
71 entities called
"units" of
11 different types. Units encapsulate
72 various objects that are relevant for system boot-up and
73 maintenance. The majority of units are configured in unit
74 configuration files, whose syntax and basic set of options is
76 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
77 however some are created automatically from other configuration,
78 dynamically from system state or programmatically at runtime.
79 Units may be
"active" (meaning started, bound, plugged in, …,
80 depending on the unit type, see below), or
"inactive" (meaning
81 stopped, unbound, unplugged, …), as well as in the process of
82 being activated or deactivated, i.e. between the two states (these
83 states are called
"activating",
"deactivating"). A special
84 "failed" state is available as well, which is very similar to
85 "inactive" and is entered when the service failed in some way
86 (process returned error code on exit, or crashed, an operation
87 timed out, or after too many restarts). If this state is entered,
88 the cause will be logged, for later reference. Note that the
89 various unit types may have a number of additional substates,
90 which are mapped to the five generalized unit states described
93 <para>The following unit types are available:
</para>
96 <listitem><para>Service units, which start and control daemons
97 and the processes they consist of. For details, see
98 <citerefentry><refentrytitle>systemd.service
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
100 <listitem><para>Socket units, which encapsulate local IPC or
101 network sockets in the system, useful for socket-based
102 activation. For details about socket units, see
103 <citerefentry><refentrytitle>systemd.socket
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
104 for details on socket-based activation and other forms of
106 <citerefentry><refentrytitle>daemon
</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para></listitem>
108 <listitem><para>Target units are useful to group units, or
109 provide well-known synchronization points during boot-up, see
110 <citerefentry><refentrytitle>systemd.target
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
112 <listitem><para>Device units expose kernel devices in systemd
113 and may be used to implement device-based activation. For
115 <citerefentry><refentrytitle>systemd.device
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
117 <listitem><para>Mount units control mount points in the file
118 system, for details see
119 <citerefentry><refentrytitle>systemd.mount
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
121 <listitem><para>Automount units provide automount capabilities,
122 for on-demand mounting of file systems as well as parallelized
124 <citerefentry><refentrytitle>systemd.automount
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
126 <listitem><para>Timer units are useful for triggering activation
127 of other units based on timers. You may find details in
128 <citerefentry><refentrytitle>systemd.timer
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
130 <listitem><para>Swap units are very similar to mount units and
131 encapsulate memory swap partitions or files of the operating
132 system. They are described in
133 <citerefentry><refentrytitle>systemd.swap
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
135 <listitem><para>Path units may be used to activate other
136 services when file system objects change or are modified. See
137 <citerefentry><refentrytitle>systemd.path
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
139 <listitem><para>Slice units may be used to group units which
140 manage system processes (such as service and scope units) in a
141 hierarchical tree for resource management purposes. See
142 <citerefentry><refentrytitle>systemd.slice
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
144 <listitem><para>Scope units are similar to service units, but
145 manage foreign processes instead of starting them as well. See
146 <citerefentry><refentrytitle>systemd.scope
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
</para></listitem>
150 <para>Units are named as their configuration files. Some units
151 have special semantics. A detailed list is available in
152 <citerefentry><refentrytitle>systemd.special
</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para>
154 <para>systemd knows various kinds of dependencies, including
155 positive and negative requirement dependencies (i.e.
156 <varname>Requires=
</varname> and
<varname>Conflicts=
</varname>) as
157 well as ordering dependencies (
<varname>After=
</varname> and
158 <varname>Before=
</varname>). NB: ordering and requirement
159 dependencies are orthogonal. If only a requirement dependency
160 exists between two units (e.g.
<filename>foo.service
</filename>
161 requires
<filename>bar.service
</filename>), but no ordering
162 dependency (e.g.
<filename>foo.service
</filename> after
163 <filename>bar.service
</filename>) and both are requested to start,
164 they will be started in parallel. It is a common pattern that both
165 requirement and ordering dependencies are placed between two
166 units. Also note that the majority of dependencies are implicitly
167 created and maintained by systemd. In most cases, it should be
168 unnecessary to declare additional dependencies manually, however
169 it is possible to do this.
</para>
171 <para>Application programs and units (via dependencies) may
172 request state changes of units. In systemd, these requests are
173 encapsulated as 'jobs' and maintained in a job queue. Jobs may
174 succeed or can fail, their execution is ordered based on the
175 ordering dependencies of the units they have been scheduled
178 <para>On boot systemd activates the target unit
179 <filename>default.target
</filename> whose job is to activate
180 on-boot services and other on-boot units by pulling them in via
181 dependencies. Usually, the unit name is just an alias (symlink) for
182 either
<filename>graphical.target
</filename> (for fully-featured
183 boots into the UI) or
<filename>multi-user.target
</filename> (for
184 limited console-only boots for use in embedded or server
185 environments, or similar; a subset of graphical.target). However,
186 it is at the discretion of the administrator to configure it as an
187 alias to any other target unit. See
188 <citerefentry><refentrytitle>systemd.special
</refentrytitle><manvolnum>7</manvolnum></citerefentry>
189 for details about these target units.
</para>
191 <para>systemd only keeps a minimal set of units loaded into memory. Specifically, the only units that are kept
192 loaded into memory are those for which at least one of the following conditions is true:
</para>
195 <listitem><para>It is in an active, activating, deactivating or failed state (i.e. in any unit state except for
<literal>inactive
</literal>)
</para></listitem>
196 <listitem><para>It has a job queued for it
</para></listitem>
197 <listitem><para>It is a dependency of at least one other unit that is loaded into memory
</para></listitem>
198 <listitem><para>It has some form of resource still allocated (e.g. a service unit that is inactive but for which
199 a process is still lingering that ignored the request to be terminated)
</para></listitem>
200 <listitem><para>It has been pinned into memory programmatically by a D-Bus call
</para></listitem>
203 <para>systemd will automatically and implicitly load units from disk — if they are not loaded yet — as soon as
204 operations are requested for them. Thus, in many respects, the fact whether a unit is loaded or not is invisible to
205 clients. Use
<command>systemctl list-units --all
</command> to comprehensively list all units currently loaded. Any
206 unit for which none of the conditions above applies is promptly unloaded. Note that when a unit is unloaded from
207 memory its accounting data is flushed out too. However, this data is generally not lost, as a journal log record
208 is generated declaring the consumed resources whenever a unit shuts down.
</para>
210 <para>Processes systemd spawns are placed in individual Linux
211 control groups named after the unit which they belong to in the
212 private systemd hierarchy. (see
<ulink
213 url=
"https://www.kernel.org/doc/Documentation/cgroup-v1/cgroups.txt">cgroups.txt
</ulink>
214 for more information about control groups, or short
"cgroups").
215 systemd uses this to effectively keep track of processes. Control
216 group information is maintained in the kernel, and is accessible
217 via the file system hierarchy (beneath
218 <filename>/sys/fs/cgroup/systemd/
</filename>), or in tools such as
219 <citerefentry project='man-pages'
><refentrytitle>systemd-cgls
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
221 <citerefentry project='man-pages'
><refentrytitle>ps
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
222 (
<command>ps xawf -eo pid,user,cgroup,args
</command> is
223 particularly useful to list all processes and the systemd units
224 they belong to.).
</para>
226 <para>systemd is compatible with the SysV init system to a large
227 degree: SysV init scripts are supported and simply read as an
228 alternative (though limited) configuration file format. The SysV
229 <filename>/dev/initctl
</filename> interface is provided, and
230 compatibility implementations of the various SysV client tools are
231 available. In addition to that, various established Unix
232 functionality such as
<filename>/etc/fstab
</filename> or the
233 <filename>utmp
</filename> database are supported.
</para>
235 <para>systemd has a minimal transaction system: if a unit is
236 requested to start up or shut down it will add it and all its
237 dependencies to a temporary transaction. Then, it will verify if
238 the transaction is consistent (i.e. whether the ordering of all
239 units is cycle-free). If it is not, systemd will try to fix it up,
240 and removes non-essential jobs from the transaction that might
241 remove the loop. Also, systemd tries to suppress non-essential
242 jobs in the transaction that would stop a running service. Finally
243 it is checked whether the jobs of the transaction contradict jobs
244 that have already been queued, and optionally the transaction is
245 aborted then. If all worked out and the transaction is consistent
246 and minimized in its impact it is merged with all already
247 outstanding jobs and added to the run queue. Effectively this
248 means that before executing a requested operation, systemd will
249 verify that it makes sense, fixing it if possible, and only
250 failing if it really cannot work.
</para>
252 <para>Note that transactions are generated independently of a unit's
253 state at runtime, hence, for example, if a start job is requested on an
254 already started unit, it will still generate a transaction and wake up any
255 inactive dependencies (and cause propagation of other jobs as per the
256 defined relationships). This is because the enqueued job is at the time of
257 execution compared to the target unit's state and is marked successful and
258 complete when both satisfy. However, this job also pulls in other
259 dependencies due to the defined relationships and thus leads to, in our
260 example, start jobs for any of those inactive units getting queued as
263 <para>systemd contains native implementations of various tasks
264 that need to be executed as part of the boot process. For example,
265 it sets the hostname or configures the loopback network device. It
266 also sets up and mounts various API file systems, such as
267 <filename>/sys
</filename> or
<filename>/proc
</filename>.
</para>
269 <para>For more information about the concepts and
270 ideas behind systemd, please refer to the
271 <ulink url=
"http://0pointer.de/blog/projects/systemd.html">Original Design Document
</ulink>.
</para>
273 <para>Note that some but not all interfaces provided
274 by systemd are covered by the
275 <ulink url=
"https://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
276 Stability Promise
</ulink>.
</para>
278 <para>Units may be generated dynamically at boot and system
279 manager reload time, for example based on other configuration
280 files or parameters passed on the kernel command line. For details, see
281 <citerefentry><refentrytitle>systemd.generator
</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para>
283 <para>The D-Bus API of
<command>systemd
</command> is described in
284 <citerefentry><refentrytitle>org.freedesktop.systemd1
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
286 <citerefentry><refentrytitle>org.freedesktop.LogControl1
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
289 <para>Systems which invoke systemd in a container or initrd environment should implement the
<ulink
290 url=
"https://systemd.io/CONTAINER_INTERFACE">Container Interface
</ulink> or
<ulink
291 url=
"https://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">initrd Interface
</ulink>
292 specifications, respectively.
</para>
296 <title>Directories
</title>
300 <term>System unit directories
</term>
302 <listitem><para>The systemd system manager reads unit
303 configuration from various directories. Packages that want to
304 install unit files shall place them in the directory returned
305 by
<command>pkg-config systemd
306 --variable=systemdsystemunitdir
</command>. Other directories
307 checked are
<filename>/usr/local/lib/systemd/system
</filename>
308 and
<filename>/usr/lib/systemd/system
</filename>. User
309 configuration always takes precedence.
<command>pkg-config
310 systemd --variable=systemdsystemconfdir
</command> returns the
311 path of the system configuration directory. Packages should
312 alter the content of these directories only with the
313 <command>enable
</command> and
<command>disable
</command>
315 <citerefentry><refentrytitle>systemctl
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
316 tool. Full list of directories is provided in
317 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
324 <term>User unit directories
</term>
326 <listitem><para>Similar rules apply for the user unit
327 directories. However, here the
328 <ulink url=
"http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
329 Base Directory specification
</ulink> is followed to find
330 units. Applications should place their unit files in the
331 directory returned by
<command>pkg-config systemd
332 --variable=systemduserunitdir
</command>. Global configuration
333 is done in the directory reported by
<command>pkg-config
334 systemd --variable=systemduserconfdir
</command>. The
335 <command>enable
</command> and
<command>disable
</command>
337 <citerefentry><refentrytitle>systemctl
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
338 tool can handle both global (i.e. for all users) and private
339 (for one user) enabling/disabling of units. Full list of
340 directories is provided in
341 <citerefentry><refentrytitle>systemd.unit
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
348 <term>SysV init scripts directory
</term>
350 <listitem><para>The location of the SysV init script directory
351 varies between distributions. If systemd cannot find a native
352 unit file for a requested service, it will look for a SysV
353 init script of the same name (with the
354 <filename>.service
</filename> suffix
355 removed).
</para></listitem>
361 <term>SysV runlevel link farm directory
</term>
363 <listitem><para>The location of the SysV runlevel link farm
364 directory varies between distributions. systemd will take the
365 link farm into account when figuring out whether a service
366 shall be enabled. Note that a service unit with a native unit
367 configuration file cannot be started by activating it in the
368 SysV runlevel link farm.
</para></listitem>
374 <title>Signals
</title>
378 <term><constant>SIGTERM
</constant></term>
380 <listitem><para>Upon receiving this signal the systemd system
381 manager serializes its state, reexecutes itself and
382 deserializes the saved state again. This is mostly equivalent
383 to
<command>systemctl daemon-reexec
</command>.
</para>
385 <para>systemd user managers will start the
386 <filename>exit.target
</filename> unit when this signal is
387 received. This is mostly equivalent to
<command>systemctl
388 --user start exit.target
389 --job-mode=replace-irreversibly
</command>.
</para></listitem>
393 <term><constant>SIGINT
</constant></term>
395 <listitem><para>Upon receiving this signal the systemd system manager will start the
396 <filename>ctrl-alt-del.target
</filename> unit. This is mostly equivalent to
397 <command>systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly
</command>. If
398 this signal is received more than
7 times per
2s, an immediate reboot is triggered. Note
400 <keycombo><keycap>Ctrl
</keycap><keycap>Alt
</keycap><keycap>Del
</keycap></keycombo> on the
401 console will trigger this signal. Hence, if a reboot is hanging, pressing
402 <keycombo><keycap>Ctrl
</keycap><keycap>Alt
</keycap><keycap>Del
</keycap></keycombo> more than
403 7 times in
2 seconds is a relatively safe way to trigger an immediate reboot.
</para>
405 <para>systemd user managers treat this signal the same way as
406 <constant>SIGTERM
</constant>.
</para></listitem>
410 <term><constant>SIGWINCH
</constant></term>
412 <listitem><para>When this signal is received the systemd
413 system manager will start the
414 <filename>kbrequest.target
</filename> unit. This is mostly
415 equivalent to
<command>systemctl start
416 kbrequest.target
</command>.
</para>
418 <para>This signal is ignored by systemd user
419 managers.
</para></listitem>
423 <term><constant>SIGPWR
</constant></term>
425 <listitem><para>When this signal is received the systemd
426 manager will start the
<filename>sigpwr.target
</filename>
427 unit. This is mostly equivalent to
<command>systemctl start
428 sigpwr.target
</command>.
</para></listitem>
432 <term><constant>SIGUSR1
</constant></term>
434 <listitem><para>When this signal is received the systemd
435 manager will try to reconnect to the D-Bus
436 bus.
</para></listitem>
440 <term><constant>SIGUSR2
</constant></term>
442 <listitem><para>When this signal is received the systemd
443 manager will log its complete state in human-readable form.
444 The data logged is the same as printed by
445 <command>systemd-analyze dump
</command>.
</para></listitem>
449 <term><constant>SIGHUP
</constant></term>
451 <listitem><para>Reloads the complete daemon configuration.
452 This is mostly equivalent to
<command>systemctl
453 daemon-reload
</command>.
</para></listitem>
457 <term><constant>SIGRTMIN+
0</constant></term>
459 <listitem><para>Enters default mode, starts the
460 <filename>default.target
</filename> unit. This is mostly
461 equivalent to
<command>systemctl isolate
462 default.target
</command>.
</para></listitem>
466 <term><constant>SIGRTMIN+
1</constant></term>
468 <listitem><para>Enters rescue mode, starts the
469 <filename>rescue.target
</filename> unit. This is mostly
470 equivalent to
<command>systemctl isolate
471 rescue.target
</command>.
</para></listitem>
475 <term><constant>SIGRTMIN+
2</constant></term>
477 <listitem><para>Enters emergency mode, starts the
478 <filename>emergency.service
</filename> unit. This is mostly
479 equivalent to
<command>systemctl isolate
480 emergency.service
</command>.
</para></listitem>
484 <term><constant>SIGRTMIN+
3</constant></term>
486 <listitem><para>Halts the machine, starts the
487 <filename>halt.target
</filename> unit. This is mostly
488 equivalent to
<command>systemctl start halt.target
489 --job-mode=replace-irreversibly
</command>.
</para>
494 <term><constant>SIGRTMIN+
4</constant></term>
496 <listitem><para>Powers off the machine, starts the
497 <filename>poweroff.target
</filename> unit. This is mostly
498 equivalent to
<command>systemctl start poweroff.target
499 --job-mode=replace-irreversibly
</command>.
</para>
504 <term><constant>SIGRTMIN+
5</constant></term>
506 <listitem><para>Reboots the machine, starts the
507 <filename>reboot.target
</filename> unit. This is mostly
508 equivalent to
<command>systemctl start reboot.target
509 --job-mode=replace-irreversibly
</command>.
</para>
514 <term><constant>SIGRTMIN+
6</constant></term>
516 <listitem><para>Reboots the machine via kexec, starts the
517 <filename>kexec.target
</filename> unit. This is mostly
518 equivalent to
<command>systemctl start kexec.target
519 --job-mode=replace-irreversibly
</command>.
</para>
524 <term><constant>SIGRTMIN+
13</constant></term>
526 <listitem><para>Immediately halts the machine.
</para></listitem>
530 <term><constant>SIGRTMIN+
14</constant></term>
532 <listitem><para>Immediately powers off the machine.
</para></listitem>
536 <term><constant>SIGRTMIN+
15</constant></term>
538 <listitem><para>Immediately reboots the machine.
</para></listitem>
542 <term><constant>SIGRTMIN+
16</constant></term>
544 <listitem><para>Immediately reboots the machine with kexec.
</para></listitem>
548 <term><constant>SIGRTMIN+
20</constant></term>
550 <listitem><para>Enables display of status messages on the
551 console, as controlled via
552 <varname>systemd.show_status=
1</varname> on the kernel command
553 line.
</para></listitem>
557 <term><constant>SIGRTMIN+
21</constant></term>
559 <listitem><para>Disables display of
560 status messages on the console, as
562 <varname>systemd.show_status=
0</varname>
563 on the kernel command
564 line.
</para></listitem>
568 <term><constant>SIGRTMIN+
22</constant></term>
570 <listitem><para>Sets the service manager's log level to
<literal>debug
</literal>, in a fashion equivalent to
571 <varname>systemd.log_level=debug
</varname> on the kernel command line.
</para></listitem>
575 <term><constant>SIGRTMIN+
23</constant></term>
577 <listitem><para>Restores the log level to its configured value. The configured value is derived from – in order
578 of priority – the value specified with
<varname>systemd.log-level=
</varname> on the kernel command line, or the
579 value specified with
<option>LogLevel=
</option> in the configuration file, or the built-in default of
580 <literal>info
</literal>.
</para></listitem>
584 <term><constant>SIGRTMIN+
24</constant></term>
586 <listitem><para>Immediately exits the manager (only available
587 for --user instances).
</para></listitem>
591 <term><constant>SIGRTMIN+
26</constant></term>
593 <listitem><para>Restores the log target to its configured value. The configured value is derived from – in
594 order of priority – the value specified with
<varname>systemd.log-target=
</varname> on the kernel command line,
595 or the value specified with
<option>LogTarget=
</option> in the configuration file, or the built-in
596 default.
</para></listitem>
600 <term><constant>SIGRTMIN+
27</constant></term>
601 <term><constant>SIGRTMIN+
28</constant></term>
603 <listitem><para>Sets the log target to
<literal>console
</literal> on
<constant>SIGRTMIN+
27</constant> (or
604 <literal>kmsg
</literal> on
<constant>SIGRTMIN+
28</constant>), in a fashion equivalent to
605 <varname>systemd.log_target=console
</varname> (or
<varname>systemd.log_target=kmsg
</varname> on
606 <constant>SIGRTMIN+
28</constant>) on the kernel command line.
</para></listitem>
612 <title>Environment
</title>
614 <variablelist class='environment-variables'
>
616 <term><varname>$SYSTEMD_LOG_COLOR
</varname></term>
617 <listitem><para>Controls whether systemd highlights important
618 log messages. This can be overridden with
619 <option>--log-color
</option>.
</para></listitem>
623 <term><varname>$SYSTEMD_LOG_LEVEL
</varname></term>
624 <listitem><para>systemd reads the log level from this
625 environment variable. This can be overridden with
626 <option>--log-level=
</option>.
</para></listitem>
630 <term><varname>$SYSTEMD_LOG_LOCATION
</varname></term>
631 <listitem><para>Controls whether systemd prints the code
632 location along with log messages. This can be overridden with
633 <option>--log-location
</option>.
</para></listitem>
637 <term><varname>$SYSTEMD_LOG_TARGET
</varname></term>
638 <listitem><para>systemd reads the log target from this
639 environment variable. This can be overridden with
640 <option>--log-target=
</option>.
</para></listitem>
644 <term><varname>$SYSTEMD_LOG_TIME
</varname></term>
645 <listitem><para>Controls whether systemd prefixes log
646 messages with the current time. This can be overridden with
647 <option>--log-time=
</option>.
</para></listitem>
651 <term><varname>$XDG_CONFIG_HOME
</varname></term>
652 <term><varname>$XDG_CONFIG_DIRS
</varname></term>
653 <term><varname>$XDG_DATA_HOME
</varname></term>
654 <term><varname>$XDG_DATA_DIRS
</varname></term>
656 <listitem><para>The systemd user manager uses these variables
657 in accordance to the
<ulink
658 url=
"http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
659 Base Directory specification
</ulink> to find its
660 configuration.
</para></listitem>
664 <term><varname>$SYSTEMD_UNIT_PATH
</varname></term>
665 <term><varname>$SYSTEMD_GENERATOR_PATH
</varname></term>
666 <term><varname>$SYSTEMD_ENVIRONMENT_GENERATOR_PATH
</varname></term>
668 <listitem><para>Controls where systemd looks for unit files and
670 <para>These variables may contain a list of paths, separated by colons
671 (
<literal>:
</literal>). When set, if the list ends with an empty
672 component (
<literal>...:
</literal>), this list is prepended to the
673 usual set of of paths. Otherwise, the specified list replaces the usual
679 <term><varname>$SYSTEMD_SYSVINIT_PATH
</varname></term>
681 <listitem><para>Controls where systemd looks for SysV init
682 scripts.
</para></listitem>
686 <term><varname>$SYSTEMD_SYSVRCND_PATH
</varname></term>
688 <listitem><para>Controls where systemd looks for SysV init
689 script runlevel link farms.
</para></listitem>
692 <xi:include href=
"less-variables.xml" xpointer=
"pager"/>
693 <xi:include href=
"less-variables.xml" xpointer=
"less"/>
694 <xi:include href=
"less-variables.xml" xpointer=
"lesscharset"/>
695 <xi:include href=
"less-variables.xml" xpointer=
"colors"/>
696 <xi:include href=
"less-variables.xml" xpointer=
"urlify"/>
699 <term><varname>$LISTEN_PID
</varname></term>
700 <term><varname>$LISTEN_FDS
</varname></term>
701 <term><varname>$LISTEN_FDNAMES
</varname></term>
703 <listitem><para>Set by systemd for supervised processes during
704 socket-based activation. See
705 <citerefentry><refentrytitle>sd_listen_fds
</refentrytitle><manvolnum>3</manvolnum></citerefentry>
706 for more information.
</para></listitem>
710 <term><varname>$NOTIFY_SOCKET
</varname></term>
712 <listitem><para>Set by systemd for supervised processes for
713 status and start-up completion notification. See
714 <citerefentry><refentrytitle>sd_notify
</refentrytitle><manvolnum>3</manvolnum></citerefentry>
715 for more information.
</para></listitem>
719 <para>For further environment variables understood by systemd and its various components, see
<ulink
720 url=
"https://systemd.io/ENVIRONMENT">Known Environment Variables
</ulink>.
</para>
724 <title>Kernel Command Line
</title>
726 <para>When run as the system instance systemd parses a number of options listed below. They can be
727 specified as kernel command line arguments
<footnote><para>If run inside a Linux container these arguments
728 may be passed as command line arguments to systemd itself, next to any of the command line options listed
729 in the Options section above. If run outside of Linux containers, these arguments are parsed from
730 <filename>/proc/cmdline
</filename> instead.
</para></footnote>, or through the
731 <literal>SystemdOptions
</literal> EFI variable (on EFI systems). The kernel command line has higher
732 priority. Following variables are understood:
</para>
734 <variablelist class='kernel-commandline-options'
>
736 <term><varname>systemd.unit=
</varname></term>
737 <term><varname>rd.systemd.unit=
</varname></term>
739 <listitem><para>Overrides the unit to activate on boot.
740 Defaults to
<filename>default.target
</filename>. This may be
741 used to temporarily boot into a different boot unit, for
742 example
<filename>rescue.target
</filename> or
743 <filename>emergency.service
</filename>. See
744 <citerefentry><refentrytitle>systemd.special
</refentrytitle><manvolnum>7</manvolnum></citerefentry>
745 for details about these units. The option prefixed with
746 <literal>rd.
</literal> is honored only in the initial RAM disk
747 (initrd), while the one that is not prefixed only in the main
748 system.
</para></listitem>
752 <term><varname>systemd.dump_core
</varname></term>
754 <listitem><para>Takes a boolean argument or enables the option if specified
755 without an argument. If enabled, the systemd manager (PID
1) dumps core when
756 it crashes. Otherwise, no core dump is created. Defaults to enabled.
</para>
761 <term><varname>systemd.crash_chvt
</varname></term>
763 <listitem><para>Takes a positive integer, or a boolean argument. Can be also
764 specified without an argument, with the same effect as a positive boolean. If
765 a positive integer (in the range
1–
63) is specified, the system manager (PID
766 1) will activate the specified virtual terminal (VT) when it
767 crashes. Defaults to disabled, meaning that no such switch is attempted. If
768 set to enabled, the VT the kernel messages are written to is selected.
773 <term><varname>systemd.crash_shell
</varname></term>
775 <listitem><para>Takes a boolean argument or enables the option if specified
776 without an argument. If enabled, the system manager (PID
1) spawns a shell
777 when it crashes, after a
10s delay. Otherwise, no shell is spawned. Defaults
778 to disabled, for security reasons, as the shell is not protected by password
779 authentication.
</para></listitem>
783 <term><varname>systemd.crash_reboot
</varname></term>
785 <listitem><para>Takes a boolean argument or enables the option if specified
786 without an argument. If enabled, the system manager (PID
1) will reboot the
787 machine automatically when it crashes, after a
10s delay. Otherwise, the
788 system will hang indefinitely. Defaults to disabled, in order to avoid a
789 reboot loop. If combined with
<varname>systemd.crash_shell
</varname>, the
790 system is rebooted after the shell exits.
</para></listitem>
794 <term><varname>systemd.confirm_spawn
</varname></term>
796 <listitem><para>Takes a boolean argument or a path to the virtual console
797 where the confirmation messages should be emitted. Can be also specified
798 without an argument, with the same effect as a positive boolean. If enabled,
799 the system manager (PID
1) asks for confirmation when spawning processes
800 using
<option>/dev/console
</option>. If a path or a console name (such as
801 <literal>ttyS0
</literal>) is provided, the virtual console pointed to by this
802 path or described by the give name will be used instead. Defaults to disabled.
807 <term><varname>systemd.service_watchdogs=
</varname></term>
809 <listitem><para>Takes a boolean argument. If disabled, all service runtime
810 watchdogs (
<option>WatchdogSec=
</option>) and emergency actions (e.g.
811 <option>OnFailure=
</option> or
<option>StartLimitAction=
</option>) are
812 ignored by the system manager (PID
1); see
813 <citerefentry><refentrytitle>systemd.service
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
814 Defaults to enabled, i.e. watchdogs and failure actions are processed
815 normally. The hardware watchdog is not affected by this
816 option.
</para></listitem>
820 <term><varname>systemd.show_status
</varname></term>
822 <listitem><para>Takes a boolean argument or the constants
<constant>error
</constant> and
823 <constant>auto
</constant>. Can be also specified without an argument, with the same effect as a
824 positive boolean. If enabled, the systemd manager (PID
1) shows terse service status updates on the
825 console during bootup. With
<constant>error
</constant>, only messages about failures are shown, but
826 boot is otherwise quiet.
<constant>auto
</constant> behaves like
<option>false
</option> until there is
827 a significant delay in boot. Defaults to enabled, unless
<option>quiet
</option> is passed as kernel
828 command line option, in which case it defaults to
<constant>error
</constant>. If specified overrides
829 the system manager configuration file option
<option>ShowStatus=
</option>, see
830 <citerefentry><refentrytitle>systemd-system.conf
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
835 <term><varname>systemd.status_unit_format=
</varname></term>
837 <listitem><para>Takes either
<option>name
</option> or
<option>description
</option> as the value. If
838 <option>name
</option>, the system manager will use unit names in status messages. If specified,
839 overrides the system manager configuration file option
<option>StatusUnitFormat=
</option>, see
840 <citerefentry><refentrytitle>systemd-system.conf
</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
845 <term><varname>systemd.log_color
</varname></term>
846 <term><varname>systemd.log_level=
</varname></term>
847 <term><varname>systemd.log_location
</varname></term>
848 <term><varname>systemd.log_target=
</varname></term>
849 <term><varname>systemd.log_time
</varname></term>
851 <listitem><para>Controls log output, with the same effect as the
852 <varname>$SYSTEMD_LOG_COLOR
</varname>,
853 <varname>$SYSTEMD_LOG_LEVEL
</varname>,
854 <varname>$SYSTEMD_LOG_LOCATION
</varname>,
855 <varname>$SYSTEMD_LOG_TARGET
</varname>,
856 <varname>$SYSTEMD_LOG_TIME
</varname>, environment variables described above.
857 <varname>systemd.log_color
</varname>,
<varname>systemd.log_location
</varname>, and
858 <varname>systemd.log_time
</varname> can be specified without an argument, with the
859 same effect as a positive boolean.
</para></listitem>
863 <term><varname>systemd.default_standard_output=
</varname></term>
864 <term><varname>systemd.default_standard_error=
</varname></term>
866 <listitem><para>Controls default standard output and error output for services and sockets. That is,
867 controls the default for
<option>StandardOutput=
</option> and
<option>StandardError=
</option> (see
868 <citerefentry><refentrytitle>systemd.exec
</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
869 details). Takes one of
<option>inherit
</option>,
<option>null
</option>,
<option>tty
</option>,
870 <option>journal
</option>,
<option>journal+console
</option>,
<option>kmsg
</option>,
871 <option>kmsg+console
</option>. If the argument is omitted
872 <varname>systemd.default-standard-output=
</varname> defaults to
<option>journal
</option> and
873 <varname>systemd.default-standard-error=
</varname> to
<option>inherit
</option>.
</para></listitem>
877 <term><varname>systemd.setenv=
</varname></term>
879 <listitem><para>Takes a string argument in the form
880 VARIABLE=VALUE. May be used to set default environment
881 variables to add to forked child processes. May be used more
882 than once to set multiple variables.
</para></listitem>
886 <term><varname>systemd.machine_id=
</varname></term>
888 <listitem><para>Takes a
32 character hex value to be
889 used for setting the machine-id. Intended mostly for
890 network booting where the same machine-id is desired
891 for every boot.
</para></listitem>
895 <term><varname>systemd.unified_cgroup_hierarchy
</varname></term>
897 <listitem><para>When specified without an argument or with a true argument,
899 <ulink url=
"https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html">unified cgroup hierarchy
</ulink>
900 (a.k.a. cgroups-v2). When specified with a false argument, fall back to
901 hybrid or full legacy cgroup hierarchy.
</para>
903 <para>If this option is not specified, the default behaviour is determined
904 during compilation (the
<option>-Ddefault-hierarchy=
</option> meson
905 option). If the kernel does not support unified cgroup hierarchy, the legacy
906 hierarchy will be used even if this option is specified.
</para>
911 <term><varname>systemd.legacy_systemd_cgroup_controller
</varname></term>
913 <listitem><para>Takes effect if the full unified cgroup hierarchy is not used
914 (see previous option). When specified without an argument or with a true
915 argument, disables the use of
"hybrid" cgroup hierarchy (i.e. a cgroups-v2
916 tree used for systemd, and
917 <ulink url=
"https://www.kernel.org/doc/Documentation/cgroup-v1/">legacy
918 cgroup hierarchy
</ulink>, a.k.a. cgroups-v1, for other controllers), and
919 forces a full
"legacy" mode. When specified with a false argument, enables
920 the use of
"hybrid" hierarchy.
</para>
922 <para>If this option is not specified, the default behaviour is determined
923 during compilation (the
<option>-Ddefault-hierarchy=
</option> meson
924 option). If the kernel does not support unified cgroup hierarchy, the legacy
925 hierarchy will be used even if this option is specified.
</para>
930 <term><varname>quiet
</varname></term>
932 <listitem><para>Turn off status output at boot, much like
933 <varname>systemd.show_status=no
</varname> would. Note that
934 this option is also read by the kernel itself and disables
935 kernel log output. Passing this option hence turns off the
936 usual output from both the system manager and the kernel.
941 <term><varname>debug
</varname></term>
943 <listitem><para>Turn on debugging output. This is equivalent
944 to
<varname>systemd.log_level=debug
</varname>. Note that this
945 option is also read by the kernel itself and enables kernel
946 debug output. Passing this option hence turns on the debug
947 output from both the system manager and the
948 kernel.
</para></listitem>
952 <term><varname>emergency
</varname></term>
953 <term><varname>rd.emergency
</varname></term>
954 <term><varname>-b
</varname></term>
956 <listitem><para>Boot into emergency mode. This is equivalent
957 to
<varname>systemd.unit=emergency.target
</varname> or
958 <varname>rd.systemd.unit=emergency.target
</varname>, respectively, and
959 provided for compatibility reasons and to be easier to type.
</para></listitem>
963 <term><varname>rescue
</varname></term>
964 <term><varname>rd.rescue
</varname></term>
965 <term><varname>single
</varname></term>
966 <term><varname>s
</varname></term>
967 <term><varname>S
</varname></term>
968 <term><varname>1</varname></term>
970 <listitem><para>Boot into rescue mode. This is equivalent to
971 <varname>systemd.unit=rescue.target
</varname> or
972 <varname>rd.systemd.unit=rescue.target
</varname>, respectively, and
973 provided for compatibility reasons and to be easier to type.
</para></listitem>
977 <term><varname>2</varname></term>
978 <term><varname>3</varname></term>
979 <term><varname>4</varname></term>
980 <term><varname>5</varname></term>
982 <listitem><para>Boot into the specified legacy SysV runlevel.
983 These are equivalent to
984 <varname>systemd.unit=runlevel2.target
</varname>,
985 <varname>systemd.unit=runlevel3.target
</varname>,
986 <varname>systemd.unit=runlevel4.target
</varname>, and
987 <varname>systemd.unit=runlevel5.target
</varname>,
988 respectively, and provided for compatibility reasons and to be
989 easier to type.
</para></listitem>
993 <term><varname>locale.LANG=
</varname></term>
994 <term><varname>locale.LANGUAGE=
</varname></term>
995 <term><varname>locale.LC_CTYPE=
</varname></term>
996 <term><varname>locale.LC_NUMERIC=
</varname></term>
997 <term><varname>locale.LC_TIME=
</varname></term>
998 <term><varname>locale.LC_COLLATE=
</varname></term>
999 <term><varname>locale.LC_MONETARY=
</varname></term>
1000 <term><varname>locale.LC_MESSAGES=
</varname></term>
1001 <term><varname>locale.LC_PAPER=
</varname></term>
1002 <term><varname>locale.LC_NAME=
</varname></term>
1003 <term><varname>locale.LC_ADDRESS=
</varname></term>
1004 <term><varname>locale.LC_TELEPHONE=
</varname></term>
1005 <term><varname>locale.LC_MEASUREMENT=
</varname></term>
1006 <term><varname>locale.LC_IDENTIFICATION=
</varname></term>
1008 <listitem><para>Set the system locale to use. This overrides
1009 the settings in
<filename>/etc/locale.conf
</filename>. For
1010 more information, see
1011 <citerefentry project='man-pages'
><refentrytitle>locale.conf
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1013 <citerefentry project='man-pages'
><refentrytitle>locale
</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1018 <para>For other kernel command line parameters understood by
1019 components of the core OS, please refer to
1020 <citerefentry><refentrytitle>kernel-command-line
</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
</para>
1024 <title>Options
</title>
1026 <para><command>systemd
</command> is only very rarely invoked directly, since it is started early and is
1027 already running by the time users may interact with it. Normally, tools like
1028 <citerefentry><refentrytitle>systemctl
</refentrytitle><manvolnum>1</manvolnum></citerefentry> are used to
1029 give commands to the manager. Since
<command>systemd
</command> is usually not invoked directly, the
1030 options listed below are mostly useful for debugging and special purposes.
</para>
1033 <title>Introspection and debugging options
</title>
1035 <para>Those options are used for testing and introspection, and
<command>systemd
</command> may
1036 be invoked with them at any time:
</para>
1040 <term><option>--dump-configuration-items
</option></term>
1042 <listitem><para>Dump understood unit configuration items. This outputs a terse but complete list of
1043 configuration items understood in unit definition files.
</para></listitem>
1047 <term><option>--dump-bus-properties
</option></term>
1049 <listitem><para>Dump exposed bus properties. This outputs a terse but complete list of properties
1050 exposed on D-Bus.
</para></listitem>
1054 <term><option>--test
</option></term>
1056 <listitem><para>Determine the initial start-up transaction (i.e. the list of jobs enqueued at
1057 start-up), dump it and exit — without actually executing any of the determined jobs. This option is
1058 useful for debugging only. Note that during regular service manager start-up additional units not
1059 shown by this operation may be started, because hardware, socket, bus or other kinds of activation
1060 might add additional jobs as the transaction is executed. Use
<option>--system
</option> to request
1061 the initial transaction of the system service manager (this is also the implied default), combine
1062 with
<option>--user
</option> to request the initial transaction of the per-user service manager
1063 instead.
</para></listitem>
1067 <term><option>--system
</option></term>
1068 <term><option>--user
</option></term>
1070 <listitem><para>When used in conjunction with
<option>--test
</option>, selects whether to calculate
1071 the initial transaction for the system instance or for a per-user instance. These options have no
1072 effect when invoked without
<option>--test
</option>, as during regular
1073 (i.e. non-
<option>--test
</option>) invocations the service manager will automatically detect
1074 whether it shall operate in system or per-user mode, by checking whether the PID it is run as is
1
1075 or not. Note that it is not supported booting and maintaining a system with the service manager
1076 running in
<option>--system
</option> mode but with a PID other than
1.
</para></listitem>
1079 <xi:include href=
"standard-options.xml" xpointer=
"help" />
1080 <xi:include href=
"standard-options.xml" xpointer=
"version" />
1085 <title>Options that duplicate kernel command line settings
</title>
1087 <para>Those options correspond directly to options listed above in
"Kernel Command Line". Both forms
1088 may be used equivalently for the system manager, but it is recommended to use the forms listed above in
1089 this context, because they are properly namespaced. When an option is specified both on the kernel
1090 command line, and as a normal command line argument, the latter has higher precedence.
</para>
1092 <para>When
<command>systemd
</command> is used a user manager, the kernel command line is ignored and
1093 the options described are understood. Nevertheless,
<command>systemd
</command> is usually started in
1094 this mode through the
1095 <citerefentry><refentrytitle>user@.service
</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1096 service, which is shared between all users, and it may be more convenient to use configuration files to
1097 modify settings, see
1098 <citerefentry><refentrytitle>systemd-user.conf
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1099 or a drop-in that specifies one of the environment variables listed above in
"Environment, see
1100 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
1104 <term><option>--unit=</option></term>
1106 <listitem><para>Set default unit to activate on startup. If not specified, defaults to
1107 <filename>default.target</filename>. See <varname>systemd.unit=</varname> above.</para></listitem>
1111 <term><option>--dump-core</option></term>
1113 <listitem><para>Enable core dumping on crash. This switch has no effect when running as user
1114 instance. Same as <varname>systemd.dump_core=</varname> above.</para></listitem>
1118 <term><option>--crash-vt=</option><replaceable>VT</replaceable></term>
1120 <listitem><para>Switch to a specific virtual console (VT) on crash. This switch has no effect when
1121 running as user instance. Same as <varname>systemd.crash_chvt=</varname> above (but not the
1122 different spelling!).</para></listitem>
1126 <term><option>--crash-shell</option></term>
1128 <listitem><para>Run a shell on crash. This switch has no effect when running as user instance. See
1129 <varname>systemd.crash_shell=</varname> above.</para></listitem>
1133 <term><option>--crash-reboot</option></term>
1135 <listitem><para>Automatically reboot the system on crash. This switch has no effect when running as
1136 user instance. See <varname>systemd.crash_reboot</varname> above.</para></listitem>
1140 <term><option>--confirm-spawn</option></term>
1142 <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as
1143 user instance. See <varname>systemd.confirm_spawn</varname> above.</para></listitem>
1147 <term><option>--show-status</option></term>
1149 <listitem><para>Show terse unit status information is shown on the console during boot-up and
1150 shutdown. See <varname>systemd.show_status</varname> above.</para></listitem>
1154 <term><option>--log-color</option></term>
1156 <listitem><para>Highlight important log messages. See <varname>systemd.log_color</varname> above.
1161 <term><option>--log-level=</option></term>
1163 <listitem><para>Set log level. See <varname>systemd.log_level</varname> above.</para></listitem>
1167 <term><option>--log-location</option></term>
1169 <listitem><para>Include code location in log messages. See <varname>systemd.log_location</varname>
1170 above.</para></listitem>
1174 <term><option>--log-target=</option></term>
1176 <listitem><para>Set log target. See <varname>systemd.log_target</varname> above.</para></listitem>
1180 <term><option>--log-time=</option></term>
1182 <listitem><para>Prefix messages with timestamp. See <varname>systemd.log_time</varname> above.
1187 <term><option>--machine-id=</option></term>
1189 <listitem><para>Override the machine-id set on the hard drive. See
1190 <varname>systemd.machine_id=</varname> above.</para></listitem>
1194 <term><option>--service-watchdogs</option></term>
1196 <listitem><para>Globally enable/disable all service watchdog timeouts and emergency actions. See
1197 <varname>systemd.service_watchdogs</varname> above.</para></listitem>
1201 <term><option>--default-standard-output=</option></term>
1202 <term><option>--default-standard-error=</option></term>
1204 <listitem><para>Sets the default output or error output for all services and sockets,
1205 respectively. See <varname>systemd.default_standard_output=</varname> and
1206 <varname>systemd.default_standard_error=</varname> above.</para></listitem>
1213 <title>Sockets and FIFOs</title>
1217 <term><filename>/run/systemd/notify</filename></term>
1219 <listitem><para>Daemon status notification socket. This is an
1220 <constant>AF_UNIX</constant> datagram socket and is used to
1221 implement the daemon notification logic as implemented by
1222 <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1227 <term><filename>/run/systemd/private</filename></term>
1229 <listitem><para>Used internally as communication channel
1231 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1232 and the systemd process. This is an
1233 <constant>AF_UNIX</constant> stream socket. This interface is
1234 private to systemd and should not be used in external
1235 projects.</para></listitem>
1239 <term><filename>/dev/initctl</filename></term>
1241 <listitem><para>Limited compatibility support for the SysV
1242 client interface, as implemented by the
1243 <filename>systemd-initctl.service</filename> unit. This is a
1244 named pipe in the file system. This interface is obsolete and
1245 should not be used in new applications.</para></listitem>
1251 <title>See Also</title>
1253 The <ulink url="https://www.freedesktop.org/wiki/Software/systemd/
">systemd Homepage</ulink>,
1254 <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1255 <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1256 <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1257 <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1258 <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1259 <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1260 <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
1261 <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1262 <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1263 <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1264 <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1265 <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1266 <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1267 <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>