man/systemd.xml

   1 <?xml version='1.0'?>
   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-or-later -->
   5
   6 <refentry id="systemd"
   7     xmlns:xi="http://www.w3.org/2001/XInclude">
   8
   9   <refentryinfo>
  10     <title>systemd</title>
  11     <productname>systemd</productname>
  12   </refentryinfo>
  13
  14   <refmeta>
  15     <refentrytitle>systemd</refentrytitle>
  16     <manvolnum>1</manvolnum>
  17   </refmeta>
  18
  19   <refnamediv>
  20     <refname>systemd</refname>
  21     <refname>init</refname>
  22     <refpurpose>systemd system and service manager</refpurpose>
  23   </refnamediv>
  24
  25   <refsynopsisdiv>
  26     <cmdsynopsis>
  27       <command>/usr/lib/systemd/systemd</command>
  28       <arg choice="opt" rep="repeat">OPTIONS</arg>
  29     </cmdsynopsis>
  30     <cmdsynopsis>
  31       <command>init</command>
  32       <arg choice="opt" rep="repeat">OPTIONS</arg>
  33       <arg choice="req">COMMAND</arg>
  34     </cmdsynopsis>
  35   </refsynopsisdiv>
  36
  37   <refsect1>
  38     <title>Description</title>
  39
  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>
  43
  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>
  48     service.</para>
  49
  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
  55     information.</para>
  56
  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>
  65   </refsect1>
  66
  67   <refsect1>
  68     <title>Concepts</title>
  69
  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
  75     described in
  76     <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
  77     however some are created automatically from other configuration
  78     files, 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
  91     here.</para>
  92
  93     <para>The following unit types are available:</para>
  94
  95     <orderedlist>
  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>
  99
 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
 105       activation, see
 106       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
 107
 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>
 111
 112       <listitem><para>Device units expose kernel devices in systemd
 113       and may be used to implement device-based activation. For
 114       details, see
 115       <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 116
 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>
 120
 121       <listitem><para>Automount units provide automount capabilities,
 122       for on-demand mounting of file systems as well as parallelized
 123       boot-up. See
 124       <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 125
 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>
 129
 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>
 134
 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>
 138
 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>
 143
 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>
 147
 148     </orderedlist>
 149
 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>
 153
 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>
 170
 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
 176     for.</para>
 177
 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>
 190
 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>
 193
 194     <orderedlist>
 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>
 201     </orderedlist>
 202
 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>
 209
 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>
 220     or
 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>
 225
 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>
 234
 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>
 251
 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
 261     well.</para>
 262
 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>
 268
 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>
 272
 273     <para>Note that some but not all interfaces provided by systemd are covered by the
 274     <ulink url="https://systemd.io/PORTABILITY_AND_STABILITY/">Interface Portability and Stability Promise</ulink>.</para>
 275
 276     <para>Units may be generated dynamically at boot and system
 277     manager reload time, for example based on other configuration
 278     files or parameters passed on the kernel command line. For details, see
 279     <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 280
 281     <para>The D-Bus API of <command>systemd</command> is described in
 282     <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 283     and
 284     <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 285     </para>
 286
 287     <para>Systems which invoke systemd in a container or initrd environment should implement the <ulink
 288     url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink> or
 289     <ulink url="https://systemd.io/INITRD_INTERFACE/">initrd Interface</ulink>
 290     specifications, respectively.</para>
 291   </refsect1>
 292
 293   <refsect1>
 294     <title>Directories</title>
 295
 296     <variablelist>
 297       <varlistentry>
 298         <term>System unit directories</term>
 299
 300         <listitem><para>The systemd system manager reads unit
 301         configuration from various directories. Packages that want to
 302         install unit files shall place them in the directory returned
 303         by <command>pkg-config systemd
 304         --variable=systemdsystemunitdir</command>. Other directories
 305         checked are <filename>/usr/local/lib/systemd/system</filename>
 306         and <filename>/usr/lib/systemd/system</filename>. User
 307         configuration always takes precedence. <command>pkg-config
 308         systemd --variable=systemdsystemconfdir</command> returns the
 309         path of the system configuration directory. Packages should
 310         alter the content of these directories only with the
 311         <command>enable</command> and <command>disable</command>
 312         commands of the
 313         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 314         tool. Full list of directories is provided in
 315         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 316         </para></listitem>
 317       </varlistentry>
 318     </variablelist>
 319
 320     <variablelist>
 321       <varlistentry>
 322         <term>User unit directories</term>
 323
 324         <listitem><para>Similar rules apply for the user unit
 325         directories. However, here the
 326         <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 327         Base Directory specification</ulink> is followed to find
 328         units. Applications should place their unit files in the
 329         directory returned by <command>pkg-config systemd
 330         --variable=systemduserunitdir</command>. Global configuration
 331         is done in the directory reported by <command>pkg-config
 332         systemd --variable=systemduserconfdir</command>. The
 333         <command>enable</command> and <command>disable</command>
 334         commands of the
 335         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 336         tool can handle both global (i.e. for all users) and private
 337         (for one user) enabling/disabling of units. Full list of
 338         directories is provided in
 339         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 340         </para></listitem>
 341       </varlistentry>
 342     </variablelist>
 343
 344     <variablelist>
 345       <varlistentry>
 346         <term>SysV init scripts directory</term>
 347
 348         <listitem><para>The location of the SysV init script directory
 349         varies between distributions. If systemd cannot find a native
 350         unit file for a requested service, it will look for a SysV
 351         init script of the same name (with the
 352         <filename>.service</filename> suffix
 353         removed).</para></listitem>
 354       </varlistentry>
 355     </variablelist>
 356
 357     <variablelist>
 358       <varlistentry>
 359         <term>SysV runlevel link farm directory</term>
 360
 361         <listitem><para>The location of the SysV runlevel link farm
 362         directory varies between distributions. systemd will take the
 363         link farm into account when figuring out whether a service
 364         shall be enabled. Note that a service unit with a native unit
 365         configuration file cannot be started by activating it in the
 366         SysV runlevel link farm.</para></listitem>
 367       </varlistentry>
 368     </variablelist>
 369   </refsect1>
 370
 371   <refsect1>
 372     <title>Signals</title>
 373
 374     <variablelist>
 375       <varlistentry>
 376         <term><constant>SIGTERM</constant></term>
 377
 378         <listitem><para>Upon receiving this signal the systemd system
 379         manager serializes its state, reexecutes itself and
 380         deserializes the saved state again. This is mostly equivalent
 381         to <command>systemctl daemon-reexec</command>.</para>
 382
 383         <para>systemd user managers will start the
 384         <filename>exit.target</filename> unit when this signal is
 385         received. This is mostly equivalent to <command>systemctl
 386         --user start exit.target
 387         --job-mode=replace-irreversibly</command>.</para></listitem>
 388       </varlistentry>
 389
 390       <varlistentry>
 391         <term><constant>SIGINT</constant></term>
 392
 393         <listitem><para>Upon receiving this signal the systemd system manager will start the
 394         <filename>ctrl-alt-del.target</filename> unit. This is mostly equivalent to
 395         <command>systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly</command>. If
 396         this signal is received more than 7 times per 2s, an immediate reboot is triggered. Note
 397         that pressing
 398         <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> on the
 399         console will trigger this signal. Hence, if a reboot is hanging, pressing
 400         <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> more than
 401         7 times in 2 seconds is a relatively safe way to trigger an immediate reboot.</para>
 402
 403         <para>systemd user managers treat this signal the same way as
 404         <constant>SIGTERM</constant>.</para></listitem>
 405       </varlistentry>
 406
 407       <varlistentry>
 408         <term><constant>SIGWINCH</constant></term>
 409
 410         <listitem><para>When this signal is received the systemd
 411         system manager will start the
 412         <filename>kbrequest.target</filename> unit. This is mostly
 413         equivalent to <command>systemctl start
 414         kbrequest.target</command>.</para>
 415
 416         <para>This signal is ignored by systemd user
 417         managers.</para></listitem>
 418       </varlistentry>
 419
 420       <varlistentry>
 421         <term><constant>SIGPWR</constant></term>
 422
 423         <listitem><para>When this signal is received the systemd
 424         manager will start the <filename>sigpwr.target</filename>
 425         unit. This is mostly equivalent to <command>systemctl start
 426         sigpwr.target</command>.</para></listitem>
 427       </varlistentry>
 428
 429       <varlistentry>
 430         <term><constant>SIGUSR1</constant></term>
 431
 432         <listitem><para>When this signal is received the systemd
 433         manager will try to reconnect to the D-Bus
 434         bus.</para></listitem>
 435       </varlistentry>
 436
 437       <varlistentry>
 438         <term><constant>SIGUSR2</constant></term>
 439
 440         <listitem><para>When this signal is received the systemd
 441         manager will log its complete state in human-readable form.
 442         The data logged is the same as printed by
 443         <command>systemd-analyze dump</command>.</para></listitem>
 444       </varlistentry>
 445
 446       <varlistentry>
 447         <term><constant>SIGHUP</constant></term>
 448
 449         <listitem><para>Reloads the complete daemon configuration.
 450         This is mostly equivalent to <command>systemctl
 451         daemon-reload</command>.</para></listitem>
 452       </varlistentry>
 453
 454       <varlistentry>
 455         <term><constant>SIGRTMIN+0</constant></term>
 456
 457         <listitem><para>Enters default mode, starts the
 458         <filename>default.target</filename> unit. This is mostly
 459         equivalent to <command>systemctl isolate
 460         default.target</command>.</para></listitem>
 461       </varlistentry>
 462
 463       <varlistentry>
 464         <term><constant>SIGRTMIN+1</constant></term>
 465
 466         <listitem><para>Enters rescue mode, starts the
 467         <filename>rescue.target</filename> unit. This is mostly
 468         equivalent to <command>systemctl isolate
 469         rescue.target</command>.</para></listitem>
 470       </varlistentry>
 471
 472       <varlistentry>
 473         <term><constant>SIGRTMIN+2</constant></term>
 474
 475         <listitem><para>Enters emergency mode, starts the
 476         <filename>emergency.service</filename> unit. This is mostly
 477         equivalent to <command>systemctl isolate
 478         emergency.service</command>.</para></listitem>
 479       </varlistentry>
 480
 481       <varlistentry>
 482         <term><constant>SIGRTMIN+3</constant></term>
 483
 484         <listitem><para>Halts the machine, starts the
 485         <filename>halt.target</filename> unit. This is mostly
 486         equivalent to <command>systemctl start halt.target
 487         --job-mode=replace-irreversibly</command>.</para>
 488         </listitem>
 489       </varlistentry>
 490
 491       <varlistentry>
 492         <term><constant>SIGRTMIN+4</constant></term>
 493
 494         <listitem><para>Powers off the machine, starts the
 495         <filename>poweroff.target</filename> unit. This is mostly
 496         equivalent to <command>systemctl start poweroff.target
 497         --job-mode=replace-irreversibly</command>.</para>
 498         </listitem>
 499       </varlistentry>
 500
 501       <varlistentry>
 502         <term><constant>SIGRTMIN+5</constant></term>
 503
 504         <listitem><para>Reboots the machine, starts the
 505         <filename>reboot.target</filename> unit. This is mostly
 506         equivalent to <command>systemctl start reboot.target
 507         --job-mode=replace-irreversibly</command>.</para>
 508         </listitem>
 509       </varlistentry>
 510
 511       <varlistentry>
 512         <term><constant>SIGRTMIN+6</constant></term>
 513
 514         <listitem><para>Reboots the machine via kexec, starts the
 515         <filename>kexec.target</filename> unit. This is mostly
 516         equivalent to <command>systemctl start kexec.target
 517         --job-mode=replace-irreversibly</command>.</para>
 518         </listitem>
 519       </varlistentry>
 520
 521       <varlistentry>
 522         <term><constant>SIGRTMIN+13</constant></term>
 523
 524         <listitem><para>Immediately halts the machine.</para></listitem>
 525       </varlistentry>
 526
 527       <varlistentry>
 528         <term><constant>SIGRTMIN+14</constant></term>
 529
 530         <listitem><para>Immediately powers off the machine.</para></listitem>
 531       </varlistentry>
 532
 533       <varlistentry>
 534         <term><constant>SIGRTMIN+15</constant></term>
 535
 536         <listitem><para>Immediately reboots the machine.</para></listitem>
 537       </varlistentry>
 538
 539       <varlistentry>
 540         <term><constant>SIGRTMIN+16</constant></term>
 541
 542         <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
 543       </varlistentry>
 544
 545       <varlistentry>
 546         <term><constant>SIGRTMIN+20</constant></term>
 547
 548         <listitem><para>Enables display of status messages on the
 549         console, as controlled via
 550         <varname>systemd.show_status=1</varname> on the kernel command
 551         line.</para></listitem>
 552       </varlistentry>
 553
 554       <varlistentry>
 555         <term><constant>SIGRTMIN+21</constant></term>
 556
 557         <listitem><para>Disables display of
 558         status messages on the console, as
 559         controlled via
 560         <varname>systemd.show_status=0</varname>
 561         on the kernel command
 562         line.</para></listitem>
 563       </varlistentry>
 564
 565       <varlistentry>
 566         <term><constant>SIGRTMIN+22</constant></term>
 567
 568         <listitem><para>Sets the service manager's log level to <literal>debug</literal>, in a fashion equivalent to
 569         <varname>systemd.log_level=debug</varname> on the kernel command line.</para></listitem>
 570       </varlistentry>
 571
 572       <varlistentry>
 573         <term><constant>SIGRTMIN+23</constant></term>
 574
 575         <listitem><para>Restores the log level to its configured value. The configured value is derived from – in order
 576         of priority – the value specified with <varname>systemd.log-level=</varname> on the kernel command line, or the
 577         value specified with <option>LogLevel=</option> in the configuration file, or the built-in default of
 578         <literal>info</literal>.</para></listitem>
 579       </varlistentry>
 580
 581       <varlistentry>
 582         <term><constant>SIGRTMIN+24</constant></term>
 583
 584         <listitem><para>Immediately exits the manager (only available
 585         for --user instances).</para></listitem>
 586       </varlistentry>
 587
 588       <varlistentry>
 589         <term><constant>SIGRTMIN+25</constant></term>
 590
 591         <listitem><para>Upon receiving this signal the systemd manager will reexecute itself. This
 592         is mostly equivalent to <command>systemctl daemon-reexec</command> except that it will be
 593         done asynchronously.</para>
 594
 595         <para>The systemd system manager treats this signal the same way as
 596         <constant>SIGTERM</constant>.</para></listitem>
 597       </varlistentry>
 598
 599       <varlistentry>
 600         <term><constant>SIGRTMIN+26</constant></term>
 601
 602         <listitem><para>Restores the log target to its configured value. The configured value is derived from – in
 603         order of priority – the value specified with <varname>systemd.log-target=</varname> on the kernel command line,
 604         or the value specified with <option>LogTarget=</option> in the configuration file, or the built-in
 605         default.</para></listitem>
 606       </varlistentry>
 607
 608       <varlistentry>
 609         <term><constant>SIGRTMIN+27</constant></term>
 610         <term><constant>SIGRTMIN+28</constant></term>
 611
 612         <listitem><para>Sets the log target to <literal>console</literal> on <constant>SIGRTMIN+27</constant> (or
 613         <literal>kmsg</literal> on <constant>SIGRTMIN+28</constant>), in a fashion equivalent to
 614         <varname>systemd.log_target=console</varname> (or <varname>systemd.log_target=kmsg</varname> on
 615         <constant>SIGRTMIN+28</constant>) on the kernel command line.</para></listitem>
 616       </varlistentry>
 617     </variablelist>
 618   </refsect1>
 619
 620   <refsect1>
 621     <title>Environment</title>
 622
 623     <para>The environment block for the system manager is initially set by the kernel. (In particular,
 624     <literal>key=value</literal> assignments on the kernel command line are turned into environment
 625     variables for PID 1). For the user manager, the system manager sets the environment as described in the
 626     "Environment Variables in Spawned Processes" section of
 627     <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
 628     <varname>DefaultEnvironment=</varname> setting in the system manager applies to all services including
 629     <filename>user@.service</filename>. Additional entries may be configured (as for any other service)
 630     through the <varname>Environment=</varname> and <varname>EnvironmentFile=</varname> settings for
 631     <filename>user@.service</filename> (see
 632     <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>). Also,
 633     additional environment variables may be set through the <varname>ManagerEnvironment=</varname> setting in
 634     <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 635     and
 636     <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 637     </para>
 638
 639     <para>Some of the variables understood by <command>systemd</command>:</para>
 640
 641     <variablelist class='environment-variables'>
 642       <varlistentry>
 643         <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
 644         <listitem><xi:include href="common-variables.xml" xpointer="log-level-body" />
 645
 646         <para>This can be overridden with <option>--log-level=</option>.</para></listitem>
 647       </varlistentry>
 648
 649       <varlistentry>
 650         <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
 651         <listitem><xi:include href="common-variables.xml" xpointer="log-color-body" />
 652
 653         <para>This can be overridden with <option>--log-color=</option>.</para></listitem>
 654       </varlistentry>
 655
 656       <varlistentry>
 657         <term><varname>$SYSTEMD_LOG_TIME</varname></term>
 658         <listitem><xi:include href="common-variables.xml" xpointer="log-time-body" />
 659
 660         <para>This can be overridden with <option>--log-time=</option>.</para></listitem>
 661       </varlistentry>
 662
 663       <varlistentry>
 664         <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
 665         <listitem><xi:include href="common-variables.xml" xpointer="log-location-body" />
 666
 667         <para>This can be overridden with <option>--log-location=</option>.</para></listitem>
 668       </varlistentry>
 669
 670       <varlistentry>
 671         <term><varname>$SYSTEMD_LOG_TID</varname></term>
 672         <listitem><xi:include href="common-variables.xml" xpointer="log-tid-body" /></listitem>
 673       </varlistentry>
 674
 675       <varlistentry>
 676         <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
 677         <listitem><xi:include href="common-variables.xml" xpointer="log-target-body" />
 678
 679         <para>This can be overridden with <option>--log-target=</option>.</para></listitem>
 680       </varlistentry>
 681
 682       <varlistentry>
 683         <term><varname>$XDG_CONFIG_HOME</varname></term>
 684         <term><varname>$XDG_CONFIG_DIRS</varname></term>
 685         <term><varname>$XDG_DATA_HOME</varname></term>
 686         <term><varname>$XDG_DATA_DIRS</varname></term>
 687
 688         <listitem><para>The systemd user manager uses these variables
 689         in accordance to the <ulink
 690         url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 691         Base Directory specification</ulink> to find its
 692         configuration.</para></listitem>
 693       </varlistentry>
 694
 695       <varlistentry>
 696         <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
 697         <term><varname>$SYSTEMD_GENERATOR_PATH</varname></term>
 698         <term><varname>$SYSTEMD_ENVIRONMENT_GENERATOR_PATH</varname></term>
 699
 700         <listitem><para>Controls where systemd looks for unit files and
 701         generators.</para>
 702         <para>These variables may contain a list of paths, separated by colons
 703         (<literal>:</literal>). When set, if the list ends with an empty
 704         component (<literal>...:</literal>), this list is prepended to the
 705         usual set of paths. Otherwise, the specified list replaces the usual
 706         set of paths.
 707         </para></listitem>
 708       </varlistentry>
 709
 710       <xi:include href="common-variables.xml" xpointer="pager"/>
 711       <xi:include href="common-variables.xml" xpointer="less"/>
 712       <xi:include href="common-variables.xml" xpointer="lesscharset"/>
 713       <xi:include href="common-variables.xml" xpointer="lesssecure"/>
 714       <xi:include href="common-variables.xml" xpointer="colors"/>
 715       <xi:include href="common-variables.xml" xpointer="urlify"/>
 716
 717       <varlistentry>
 718         <term><varname>$LISTEN_PID</varname></term>
 719         <term><varname>$LISTEN_FDS</varname></term>
 720         <term><varname>$LISTEN_FDNAMES</varname></term>
 721
 722         <listitem><para>Set by systemd for supervised processes during
 723         socket-based activation. See
 724         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 725         for more information.</para></listitem>
 726       </varlistentry>
 727
 728       <varlistentry>
 729         <term><varname>$NOTIFY_SOCKET</varname></term>
 730
 731         <listitem><para>Set by systemd for supervised processes for
 732         status and start-up completion notification. See
 733         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 734         for more information.</para></listitem>
 735       </varlistentry>
 736     </variablelist>
 737
 738     <para>For further environment variables understood by systemd and its various components, see <ulink
 739     url="https://systemd.io/ENVIRONMENT">Known Environment Variables</ulink>.</para>
 740   </refsect1>
 741
 742   <refsect1>
 743     <title>Kernel Command Line</title>
 744
 745     <para>When run as the system instance, systemd parses a number of options listed below. They can be
 746     specified as kernel command line arguments which are parsed from a number of sources depending on the
 747     environment in which systemd is executed. If run inside a Linux container, these options are parsed from
 748     the command line arguments passed to systemd itself, next to any of the command line options listed in
 749     the Options section above. If run outside of Linux containers, these arguments are parsed from
 750     <filename>/proc/cmdline</filename> and from the <literal>SystemdOptions</literal> EFI variable
 751     (on EFI systems) instead. Options from <filename>/proc/cmdline</filename> have higher priority. The
 752     following variables are understood:</para>
 753
 754     <variablelist class='kernel-commandline-options'>
 755       <varlistentry>
 756         <term><varname>systemd.unit=</varname></term>
 757         <term><varname>rd.systemd.unit=</varname></term>
 758
 759         <listitem><para>Overrides the unit to activate on boot.
 760         Defaults to <filename>default.target</filename>. This may be
 761         used to temporarily boot into a different boot unit, for
 762         example <filename>rescue.target</filename> or
 763         <filename>emergency.service</filename>. See
 764         <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 765         for details about these units. The option prefixed with
 766         <literal>rd.</literal> is honored only in the initial RAM disk
 767         (initrd), while the one that is not prefixed only in the main
 768         system.</para></listitem>
 769       </varlistentry>
 770
 771       <varlistentry>
 772         <term><varname>systemd.dump_core</varname></term>
 773
 774         <listitem><para>Takes a boolean argument or enables the option if specified
 775         without an argument. If enabled, the systemd manager (PID 1) dumps core when
 776         it crashes. Otherwise, no core dump is created. Defaults to enabled.</para>
 777         </listitem>
 778       </varlistentry>
 779
 780       <varlistentry>
 781         <term><varname>systemd.crash_chvt</varname></term>
 782
 783         <listitem><para>Takes a positive integer, or a boolean argument. Can be also specified without an
 784         argument, with the same effect as a positive boolean. If a positive integer (in the range 1–63) is
 785         specified, the system manager (PID 1) will activate the specified virtual terminal when it crashes.
 786         Defaults to disabled, meaning that no such switch is attempted. If set to enabled, the virtual
 787         terminal the kernel messages are written to is used instead.</para></listitem>
 788       </varlistentry>
 789
 790       <varlistentry>
 791         <term><varname>systemd.crash_shell</varname></term>
 792
 793         <listitem><para>Takes a boolean argument or enables the option if specified
 794         without an argument. If enabled, the system manager (PID 1) spawns a shell
 795         when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults
 796         to disabled, for security reasons, as the shell is not protected by password
 797         authentication.</para></listitem>
 798       </varlistentry>
 799
 800       <varlistentry>
 801         <term><varname>systemd.crash_reboot</varname></term>
 802
 803         <listitem><para>Takes a boolean argument or enables the option if specified
 804         without an argument. If enabled, the system manager (PID 1) will reboot the
 805         machine automatically when it crashes, after a 10s delay.  Otherwise, the
 806         system will hang indefinitely. Defaults to disabled, in order to avoid a
 807         reboot loop. If combined with <varname>systemd.crash_shell</varname>, the
 808         system is rebooted after the shell exits.</para></listitem>
 809       </varlistentry>
 810
 811       <varlistentry>
 812         <term><varname>systemd.confirm_spawn</varname></term>
 813
 814         <listitem><para>Takes a boolean argument or a path to the virtual console
 815         where the confirmation messages should be emitted. Can be also specified
 816         without an argument, with the same effect as a positive boolean. If enabled,
 817         the system manager (PID 1) asks for confirmation when spawning processes
 818         using <option>/dev/console</option>. If a path or a console name (such as
 819         <literal>ttyS0</literal>) is provided, the virtual console pointed to by this
 820         path or described by the give name will be used instead. Defaults to disabled.
 821         </para></listitem>
 822       </varlistentry>
 823
 824       <varlistentry>
 825         <term><varname>systemd.service_watchdogs=</varname></term>
 826
 827         <listitem><para>Takes a boolean argument. If disabled, all service runtime
 828         watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g.
 829         <option>OnFailure=</option> or <option>StartLimitAction=</option>) are
 830         ignored by the system manager (PID 1); see
 831         <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 832         Defaults to enabled, i.e. watchdogs and failure actions are processed
 833         normally. The hardware watchdog is not affected by this
 834         option.</para></listitem>
 835       </varlistentry>
 836
 837       <varlistentry>
 838         <term><varname>systemd.show_status</varname></term>
 839
 840         <listitem><para>Takes a boolean argument or the constants <constant>error</constant> and
 841         <constant>auto</constant>. Can be also specified without an argument, with the same effect as a
 842         positive boolean. If enabled, the systemd manager (PID 1) shows terse service status updates on the
 843         console during bootup. With <constant>error</constant>, only messages about failures are shown, but
 844         boot is otherwise quiet. <constant>auto</constant> behaves like <option>false</option> until there is
 845         a significant delay in boot. Defaults to enabled, unless <option>quiet</option> is passed as kernel
 846         command line option, in which case it defaults to <constant>error</constant>. If specified overrides
 847         the system manager configuration file option <option>ShowStatus=</option>, see
 848         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 849         </para></listitem>
 850       </varlistentry>
 851
 852       <varlistentry>
 853         <term><varname>systemd.status_unit_format=</varname></term>
 854
 855         <listitem><para>Takes <option>name</option>, <option>description</option> or
 856         <option>combined</option> as the value. If <option>name</option>, the system manager will use unit
 857         names in status messages. If <option>combined</option>, the system manager will use unit names and
 858         description in status messages. When specified, overrides the system manager configuration file
 859         option <option>StatusUnitFormat=</option>, see
 860         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 861         </para></listitem>
 862       </varlistentry>
 863
 864       <varlistentry>
 865         <term><varname>systemd.log_color</varname></term>
 866         <term><varname>systemd.log_level=</varname></term>
 867         <term><varname>systemd.log_location</varname></term>
 868         <term><varname>systemd.log_target=</varname></term>
 869         <term><varname>systemd.log_time</varname></term>
 870         <term><varname>systemd.log_tid</varname></term>
 871
 872         <listitem><para>Controls log output, with the same effect as the
 873         <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>,
 874         <varname>$SYSTEMD_LOG_LOCATION</varname>, <varname>$SYSTEMD_LOG_TARGET</varname>,
 875         <varname>$SYSTEMD_LOG_TIME</varname>, and <varname>$SYSTEMD_LOG_TID</varname> environment variables
 876         described above. <varname>systemd.log_color</varname>, <varname>systemd.log_location</varname>,
 877         <varname>systemd.log_time</varname>, and <varname>systemd.log_tid=</varname> can be specified without
 878         an argument, with the same effect as a positive boolean.</para></listitem>
 879       </varlistentry>
 880
 881       <varlistentry>
 882         <term><varname>systemd.default_standard_output=</varname></term>
 883         <term><varname>systemd.default_standard_error=</varname></term>
 884
 885         <listitem><para>Controls default standard output and error output for services and sockets. That is,
 886         controls the default for <option>StandardOutput=</option> and <option>StandardError=</option> (see
 887         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
 888         details). Takes one of <option>inherit</option>, <option>null</option>, <option>tty</option>,
 889         <option>journal</option>, <option>journal+console</option>, <option>kmsg</option>,
 890         <option>kmsg+console</option>. If the argument is omitted
 891         <varname>systemd.default-standard-output=</varname> defaults to <option>journal</option> and
 892         <varname>systemd.default-standard-error=</varname> to <option>inherit</option>.</para></listitem>
 893       </varlistentry>
 894
 895       <varlistentry>
 896         <term><varname>systemd.setenv=</varname></term>
 897
 898         <listitem><para>Takes a string argument in the form
 899         VARIABLE=VALUE. May be used to set default environment
 900         variables to add to forked child processes. May be used more
 901         than once to set multiple variables.</para></listitem>
 902       </varlistentry>
 903
 904       <varlistentry>
 905         <term><varname>systemd.machine_id=</varname></term>
 906
 907         <listitem><para>Takes a 32 character hex value to be
 908         used for setting the machine-id. Intended mostly for
 909         network booting where the same machine-id is desired
 910         for every boot.</para></listitem>
 911       </varlistentry>
 912
 913       <varlistentry>
 914         <term><varname>systemd.unified_cgroup_hierarchy</varname></term>
 915
 916         <listitem><para>When specified without an argument or with a true argument,
 917         enables the usage of
 918         <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html">unified cgroup hierarchy</ulink>
 919         (a.k.a. cgroups-v2). When specified with a false argument, fall back to
 920         hybrid or full legacy cgroup hierarchy.</para>
 921
 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>
 926         </listitem>
 927       </varlistentry>
 928
 929       <varlistentry>
 930         <term><varname>systemd.legacy_systemd_cgroup_controller</varname></term>
 931
 932         <listitem><para>Takes effect if the full unified cgroup hierarchy is not used
 933         (see previous option). When specified without an argument or with a true
 934         argument, disables the use of "hybrid" cgroup hierarchy (i.e. a cgroups-v2
 935         tree used for systemd, and
 936         <ulink url="https://www.kernel.org/doc/Documentation/cgroup-v1/">legacy
 937         cgroup hierarchy</ulink>, a.k.a. cgroups-v1, for other controllers), and
 938         forces a full "legacy" mode. When specified with a false argument, enables
 939         the use of "hybrid" hierarchy.</para>
 940
 941         <para>If this option is not specified, the default behaviour is determined
 942         during compilation (the <option>-Ddefault-hierarchy=</option> meson
 943         option). If the kernel does not support unified cgroup hierarchy, the legacy
 944         hierarchy will be used  even if this option is specified.</para>
 945         </listitem>
 946       </varlistentry>
 947
 948       <varlistentry>
 949         <term><varname>systemd.set_credential=</varname></term>
 950
 951         <listitem><para>Sets a system credential, which can then be propagated to system services using the
 952         <varname>LoadCredential=</varname> setting, see
 953         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
 954         details. Takes a pair of credential name and value, separated by a colon. Note that the kernel
 955         command line is typically accessible by unprivileged programs in
 956         <filename>/proc/cmdline</filename>. Thus, this mechanism is not suitable for transferring sensitive
 957         data. Use it only for data that is not sensitive (e.g. public keys/certificates, rather than private
 958         keys), or in testing/debugging environments.</para>
 959
 960         <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
 961         Credentials</ulink> documentation.</para></listitem>
 962       </varlistentry>
 963
 964       <varlistentry>
 965         <term><varname>systemd.import_credentials=</varname></term>
 966
 967         <listitem><para>Takes a boolean argument. If false disables importing credentials from the kernel
 968         command line, qemu_fw_cfg subsystem or the kernel command line.</para></listitem>
 969       </varlistentry>
 970
 971       <varlistentry>
 972         <term><varname>quiet</varname></term>
 973
 974         <listitem><para>Turn off status output at boot, much like
 975         <varname>systemd.show_status=no</varname> would. Note that
 976         this option is also read by the kernel itself and disables
 977         kernel log output. Passing this option hence turns off the
 978         usual output from both the system manager and the kernel.
 979         </para></listitem>
 980       </varlistentry>
 981
 982       <varlistentry>
 983         <term><varname>debug</varname></term>
 984
 985         <listitem><para>Turn on debugging output. This is equivalent
 986         to <varname>systemd.log_level=debug</varname>. Note that this
 987         option is also read by the kernel itself and enables kernel
 988         debug output. Passing this option hence turns on the debug
 989         output from both the system manager and the
 990         kernel.</para></listitem>
 991       </varlistentry>
 992
 993       <varlistentry>
 994         <term><varname>emergency</varname></term>
 995         <term><varname>rd.emergency</varname></term>
 996         <term><varname>-b</varname></term>
 997
 998         <listitem><para>Boot into emergency mode. This is equivalent
 999         to <varname>systemd.unit=emergency.target</varname> or
1000         <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
1001         provided for compatibility reasons and to be easier to type.</para></listitem>
1002       </varlistentry>
1003
1004       <varlistentry>
1005         <term><varname>rescue</varname></term>
1006         <term><varname>rd.rescue</varname></term>
1007         <term><varname>single</varname></term>
1008         <term><varname>s</varname></term>
1009         <term><varname>S</varname></term>
1010         <term><varname>1</varname></term>
1011
1012         <listitem><para>Boot into rescue mode. This is equivalent to
1013         <varname>systemd.unit=rescue.target</varname> or
1014         <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
1015         provided for compatibility reasons and to be easier to type.</para></listitem>
1016       </varlistentry>
1017
1018       <varlistentry>
1019         <term><varname>2</varname></term>
1020         <term><varname>3</varname></term>
1021         <term><varname>4</varname></term>
1022         <term><varname>5</varname></term>
1023
1024         <listitem><para>Boot into the specified legacy SysV runlevel.
1025         These are equivalent to
1026         <varname>systemd.unit=runlevel2.target</varname>,
1027         <varname>systemd.unit=runlevel3.target</varname>,
1028         <varname>systemd.unit=runlevel4.target</varname>, and
1029         <varname>systemd.unit=runlevel5.target</varname>,
1030         respectively, and provided for compatibility reasons and to be
1031         easier to type.</para></listitem>
1032       </varlistentry>
1033
1034       <varlistentry>
1035         <term><varname>locale.LANG=</varname></term>
1036         <term><varname>locale.LANGUAGE=</varname></term>
1037         <term><varname>locale.LC_CTYPE=</varname></term>
1038         <term><varname>locale.LC_NUMERIC=</varname></term>
1039         <term><varname>locale.LC_TIME=</varname></term>
1040         <term><varname>locale.LC_COLLATE=</varname></term>
1041         <term><varname>locale.LC_MONETARY=</varname></term>
1042         <term><varname>locale.LC_MESSAGES=</varname></term>
1043         <term><varname>locale.LC_PAPER=</varname></term>
1044         <term><varname>locale.LC_NAME=</varname></term>
1045         <term><varname>locale.LC_ADDRESS=</varname></term>
1046         <term><varname>locale.LC_TELEPHONE=</varname></term>
1047         <term><varname>locale.LC_MEASUREMENT=</varname></term>
1048         <term><varname>locale.LC_IDENTIFICATION=</varname></term>
1049
1050         <listitem><para>Set the system locale to use. This overrides
1051         the settings in <filename>/etc/locale.conf</filename>. For
1052         more information, see
1053         <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1054         and
1055         <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1056         </para></listitem>
1057       </varlistentry>
1058     </variablelist>
1059
1060     <para>For other kernel command line parameters understood by
1061     components of the core OS, please refer to
1062     <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1063   </refsect1>
1064
1065   <refsect1>
1066     <title>Options</title>
1067
1068     <para><command>systemd</command> is only very rarely invoked directly, since it is started early and is
1069     already running by the time users may interact with it. Normally, tools like
1070     <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> are used to
1071     give commands to the manager. Since <command>systemd</command> is usually not invoked directly, the
1072     options listed below are mostly useful for debugging and special purposes.</para>
1073
1074     <refsect2>
1075       <title>Introspection and debugging options</title>
1076
1077       <para>Those options are used for testing and introspection, and <command>systemd</command> may
1078       be invoked with them at any time:</para>
1079
1080       <variablelist>
1081         <varlistentry>
1082           <term><option>--dump-configuration-items</option></term>
1083
1084           <listitem><para>Dump understood unit configuration items. This outputs a terse but complete list of
1085           configuration items understood in unit definition files.</para></listitem>
1086         </varlistentry>
1087
1088         <varlistentry>
1089           <term><option>--dump-bus-properties</option></term>
1090
1091           <listitem><para>Dump exposed bus properties. This outputs a terse but complete list of properties
1092           exposed on D-Bus.</para></listitem>
1093         </varlistentry>
1094
1095         <varlistentry>
1096           <term><option>--test</option></term>
1097
1098           <listitem><para>Determine the initial start-up transaction (i.e. the list of jobs enqueued at
1099           start-up), dump it and exit — without actually executing any of the determined jobs. This option is
1100           useful for debugging only. Note that during regular service manager start-up additional units not
1101           shown by this operation may be started, because hardware, socket, bus or other kinds of activation
1102           might add additional jobs as the transaction is executed. Use <option>--system</option> to request
1103           the initial transaction of the system service manager (this is also the implied default), combine
1104           with <option>--user</option> to request the initial transaction of the per-user service manager
1105           instead.</para></listitem>
1106         </varlistentry>
1107
1108         <varlistentry>
1109           <term><option>--system</option></term>
1110           <term><option>--user</option></term>
1111
1112           <listitem><para>When used in conjunction with <option>--test</option>, selects whether to calculate
1113           the initial transaction for the system instance or for a per-user instance. These options have no
1114           effect when invoked without <option>--test</option>, as during regular
1115           (i.e. non-<option>--test</option>) invocations the service manager will automatically detect
1116           whether it shall operate in system or per-user mode, by checking whether the PID it is run as is 1
1117           or not. Note that it is not supported booting and maintaining a system with the service manager
1118           running in <option>--system</option> mode but with a PID other than 1.</para></listitem>
1119         </varlistentry>
1120
1121         <xi:include href="standard-options.xml" xpointer="help" />
1122         <xi:include href="standard-options.xml" xpointer="version" />
1123       </variablelist>
1124     </refsect2>
1125
1126     <refsect2>
1127       <title>Options that duplicate kernel command line settings</title>
1128
1129       <para>Those options correspond directly to options listed above in "Kernel Command Line". Both forms
1130       may be used equivalently for the system manager, but it is recommended to use the forms listed above in
1131       this context, because they are properly namespaced. When an option is specified both on the kernel
1132       command line and as a normal command line argument, the latter has higher precedence.</para>
1133
1134       <para>When <command>systemd</command> is used as a user manager, the kernel command line is ignored and
1135       only the options described below are understood. Nevertheless, <command>systemd</command> is usually
1136       started in this mode through the
1137       <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1138       service, which is shared between all users. It may be more convenient to use configuration files to
1139       modify settings (see
1140       <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
1141       or environment variables. See the "Environment" section above for a discussion of how the environment
1142       block is set.</para>
1143
1144       <variablelist>
1145         <varlistentry>
1146           <term><option>--unit=</option></term>
1147
1148           <listitem><para>Set default unit to activate on startup. If not specified, defaults to
1149           <filename>default.target</filename>. See <varname>systemd.unit=</varname> above.</para></listitem>
1150         </varlistentry>
1151
1152         <varlistentry>
1153           <term><option>--dump-core</option></term>
1154
1155           <listitem><para>Enable core dumping on crash. This switch has no effect when running as user
1156           instance. Same as <varname>systemd.dump_core=</varname> above.</para></listitem>
1157         </varlistentry>
1158
1159         <varlistentry>
1160           <term><option>--crash-vt=</option><replaceable>VT</replaceable></term>
1161
1162           <listitem><para>Switch to a specific virtual console (VT) on crash. This switch has no effect when
1163           running as user instance. Same as <varname>systemd.crash_chvt=</varname> above (but not the
1164           different spelling!).</para></listitem>
1165         </varlistentry>
1166
1167         <varlistentry>
1168           <term><option>--crash-shell</option></term>
1169
1170           <listitem><para>Run a shell on crash. This switch has no effect when running as user instance. See
1171           <varname>systemd.crash_shell=</varname> above.</para></listitem>
1172         </varlistentry>
1173
1174         <varlistentry>
1175           <term><option>--crash-reboot</option></term>
1176
1177           <listitem><para>Automatically reboot the system on crash. This switch has no effect when running as
1178           user instance. See <varname>systemd.crash_reboot</varname> above.</para></listitem>
1179         </varlistentry>
1180
1181         <varlistentry>
1182           <term><option>--confirm-spawn</option></term>
1183
1184           <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as
1185           user instance. See <varname>systemd.confirm_spawn</varname> above.</para></listitem>
1186         </varlistentry>
1187
1188         <varlistentry>
1189           <term><option>--show-status</option></term>
1190
1191           <listitem><para>Show terse unit status information on the console during boot-up and shutdown. See
1192           <varname>systemd.show_status</varname> above.</para></listitem>
1193         </varlistentry>
1194
1195         <varlistentry>
1196           <term><option>--log-color</option></term>
1197
1198           <listitem><para>Highlight important log messages. See <varname>systemd.log_color</varname> above.
1199           </para></listitem>
1200         </varlistentry>
1201
1202         <varlistentry>
1203           <term><option>--log-level=</option></term>
1204
1205           <listitem><para>Set log level. See <varname>systemd.log_level</varname> above.</para></listitem>
1206         </varlistentry>
1207
1208         <varlistentry>
1209           <term><option>--log-location</option></term>
1210
1211           <listitem><para>Include code location in log messages. See <varname>systemd.log_location</varname>
1212           above.</para></listitem>
1213         </varlistentry>
1214
1215         <varlistentry>
1216           <term><option>--log-target=</option></term>
1217
1218           <listitem><para>Set log target. See <varname>systemd.log_target</varname> above.</para></listitem>
1219         </varlistentry>
1220
1221         <varlistentry>
1222           <term><option>--log-time=</option></term>
1223
1224           <listitem><para>Prefix console messages with timestamp. See <varname>systemd.log_time</varname> above.
1225           </para></listitem>
1226         </varlistentry>
1227
1228         <varlistentry>
1229           <term><option>--machine-id=</option></term>
1230
1231           <listitem><para>Override the machine-id set on the hard drive. See
1232           <varname>systemd.machine_id=</varname> above.</para></listitem>
1233         </varlistentry>
1234
1235         <varlistentry>
1236           <term><option>--service-watchdogs</option></term>
1237
1238           <listitem><para>Globally enable/disable all service watchdog timeouts and emergency actions. See
1239           <varname>systemd.service_watchdogs</varname> above.</para></listitem>
1240         </varlistentry>
1241
1242         <varlistentry>
1243           <term><option>--default-standard-output=</option></term>
1244           <term><option>--default-standard-error=</option></term>
1245
1246           <listitem><para>Sets the default output or error output for all services and sockets,
1247           respectively. See <varname>systemd.default_standard_output=</varname> and
1248           <varname>systemd.default_standard_error=</varname> above.</para></listitem>
1249         </varlistentry>
1250       </variablelist>
1251     </refsect2>
1252   </refsect1>
1253
1254   <refsect1>
1255     <title>Sockets and FIFOs</title>
1256
1257     <variablelist>
1258       <varlistentry>
1259         <term><filename>/run/systemd/notify</filename></term>
1260
1261         <listitem><para>Daemon status notification socket. This is an
1262         <constant>AF_UNIX</constant> datagram socket and is used to
1263         implement the daemon notification logic as implemented by
1264         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1265
1266       </varlistentry>
1267
1268       <varlistentry>
1269         <term><filename>/run/systemd/private</filename></term>
1270
1271         <listitem><para>Used internally as communication channel
1272         between
1273         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1274         and the systemd process. This is an
1275         <constant>AF_UNIX</constant> stream socket. This interface is
1276         private to systemd and should not be used in external
1277         projects.</para></listitem>
1278       </varlistentry>
1279
1280       <varlistentry>
1281         <term><filename>/dev/initctl</filename></term>
1282
1283         <listitem><para>Limited compatibility support for the SysV
1284         client interface, as implemented by the
1285         <filename>systemd-initctl.service</filename> unit. This is a
1286         named pipe in the file system. This interface is obsolete and
1287         should not be used in new applications.</para></listitem>
1288       </varlistentry>
1289     </variablelist>
1290   </refsect1>
1291
1292   <refsect1>
1293     <title>See Also</title>
1294     <para>
1295       The <ulink url="https://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,
1296       <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1297       <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1298       <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1299       <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1300       <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1301       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1302       <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
1303       <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1304       <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1305       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1306       <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1307       <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1308       <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1309       <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1310     </para>
1311   </refsect1>
1312
1313 </refentry>