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>On first boot, <command>systemd</command> will enable or disable units according to preset policy.
 192     See <citerefentry><refentrytitle>systemd.preset</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 193     and "First Boot Semantics" in
 194     <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para>
 195
 196     <para>systemd only keeps a minimal set of units loaded into memory. Specifically, the only units that are
 197     kept loaded into memory are those for which at least one of the following conditions is true:</para>
 198
 199     <orderedlist>
 200       <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>
 201       <listitem><para>It has a job queued for it</para></listitem>
 202       <listitem><para>It is a dependency of at least one other unit that is loaded into memory</para></listitem>
 203       <listitem><para>It has some form of resource still allocated (e.g. a service unit that is inactive but for which
 204       a process is still lingering that ignored the request to be terminated)</para></listitem>
 205       <listitem><para>It has been pinned into memory programmatically by a D-Bus call</para></listitem>
 206     </orderedlist>
 207
 208     <para>systemd will automatically and implicitly load units from disk — if they are not loaded yet — as soon as
 209     operations are requested for them. Thus, in many respects, the fact whether a unit is loaded or not is invisible to
 210     clients. Use <command>systemctl list-units --all</command> to comprehensively list all units currently loaded. Any
 211     unit for which none of the conditions above applies is promptly unloaded. Note that when a unit is unloaded from
 212     memory its accounting data is flushed out too. However, this data is generally not lost, as a journal log record
 213     is generated declaring the consumed resources whenever a unit shuts down.</para>
 214
 215     <para>Processes systemd spawns are placed in individual Linux control groups named after the unit which
 216     they belong to in the private systemd hierarchy. (see <ulink
 217     url="https://docs.kernel.org/admin-guide/cgroup-v2.html">Control Groups v2</ulink> for more information
 218     about control groups, or short "cgroups").  systemd uses this to effectively keep track of
 219     processes. Control group information is maintained in the kernel, and is accessible via the file system
 220     hierarchy (beneath <filename>/sys/fs/cgroup/</filename>), or in tools such as <citerefentry
 221     project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry> or
 222     <citerefentry
 223     project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry> (<command>ps
 224     xawf -eo pid,user,cgroup,args</command> is particularly useful to list all processes and the systemd
 225     units they belong to.).</para>
 226
 227     <para>systemd is compatible with the SysV init system to a large
 228     degree: SysV init scripts are supported and simply read as an
 229     alternative (though limited) configuration file format. The SysV
 230     <filename>/dev/initctl</filename> interface is provided, and
 231     compatibility implementations of the various SysV client tools are
 232     available. In addition to that, various established Unix
 233     functionality such as <filename>/etc/fstab</filename> or the
 234     <filename>utmp</filename> database are supported.</para>
 235
 236     <para>systemd has a minimal transaction system: if a unit is
 237     requested to start up or shut down it will add it and all its
 238     dependencies to a temporary transaction. Then, it will verify if
 239     the transaction is consistent (i.e. whether the ordering of all
 240     units is cycle-free). If it is not, systemd will try to fix it up,
 241     and removes non-essential jobs from the transaction that might
 242     remove the loop. Also, systemd tries to suppress non-essential
 243     jobs in the transaction that would stop a running service. Finally
 244     it is checked whether the jobs of the transaction contradict jobs
 245     that have already been queued, and optionally the transaction is
 246     aborted then. If all worked out and the transaction is consistent
 247     and minimized in its impact it is merged with all already
 248     outstanding jobs and added to the run queue. Effectively this
 249     means that before executing a requested operation, systemd will
 250     verify that it makes sense, fixing it if possible, and only
 251     failing if it really cannot work.</para>
 252
 253     <para>Note that transactions are generated independently of a unit's
 254     state at runtime, hence, for example, if a start job is requested on an
 255     already started unit, it will still generate a transaction and wake up any
 256     inactive dependencies (and cause propagation of other jobs as per the
 257     defined relationships). This is because the enqueued job is at the time of
 258     execution compared to the target unit's state and is marked successful and
 259     complete when both satisfy. However, this job also pulls in other
 260     dependencies due to the defined relationships and thus leads to, in our
 261     example, start jobs for any of those inactive units getting queued as
 262     well.</para>
 263
 264     <para>systemd contains native implementations of various tasks
 265     that need to be executed as part of the boot process. For example,
 266     it sets the hostname or configures the loopback network device. It
 267     also sets up and mounts various API file systems, such as
 268     <filename>/sys/</filename> or <filename>/proc/</filename>.</para>
 269
 270     <para>For more information about the concepts and
 271     ideas behind systemd, please refer to the
 272     <ulink url="https://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para>
 273
 274     <para>Note that some but not all interfaces provided by systemd are covered by the
 275     <ulink url="https://systemd.io/PORTABILITY_AND_STABILITY/">Interface Portability and Stability Promise</ulink>.</para>
 276
 277     <para>Units may be generated dynamically at boot and system
 278     manager reload time, for example based on other configuration
 279     files or parameters passed on the kernel command line. For details, see
 280     <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 281
 282     <para>The D-Bus API of <command>systemd</command> is described in
 283     <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 284     and
 285     <citerefentry><refentrytitle>org.freedesktop.LogControl1</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 286     </para>
 287
 288     <para>Systems which invoke systemd in a container or initrd environment should implement the <ulink
 289     url="https://systemd.io/CONTAINER_INTERFACE">Container Interface</ulink> or
 290     <ulink url="https://systemd.io/INITRD_INTERFACE/">initrd Interface</ulink>
 291     specifications, respectively.</para>
 292   </refsect1>
 293
 294   <refsect1>
 295     <title>Directories</title>
 296
 297     <variablelist>
 298       <varlistentry>
 299         <term>System unit directories</term>
 300
 301         <listitem><para>The systemd system manager reads unit
 302         configuration from various directories. Packages that want to
 303         install unit files shall place them in the directory returned
 304         by <command>pkg-config systemd
 305         --variable=systemdsystemunitdir</command>. Other directories
 306         checked are <filename>/usr/local/lib/systemd/system</filename>
 307         and <filename>/usr/lib/systemd/system</filename>. User
 308         configuration always takes precedence. <command>pkg-config
 309         systemd --variable=systemdsystemconfdir</command> returns the
 310         path of the system configuration directory. Packages should
 311         alter the content of these directories only with the
 312         <command>enable</command> and <command>disable</command>
 313         commands of the
 314         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 315         tool. Full list of directories is provided in
 316         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 317         </para></listitem>
 318       </varlistentry>
 319     </variablelist>
 320
 321     <variablelist>
 322       <varlistentry>
 323         <term>User unit directories</term>
 324
 325         <listitem><para>Similar rules apply for the user unit
 326         directories. However, here the
 327         <ulink url="https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 328         Base Directory specification</ulink> is followed to find
 329         units. Applications should place their unit files in the
 330         directory returned by <command>pkg-config systemd
 331         --variable=systemduserunitdir</command>. Global configuration
 332         is done in the directory reported by <command>pkg-config
 333         systemd --variable=systemduserconfdir</command>. The
 334         <command>enable</command> and <command>disable</command>
 335         commands of the
 336         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 337         tool can handle both global (i.e. for all users) and private
 338         (for one user) enabling/disabling of units. Full list of
 339         directories is provided in
 340         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 341         </para></listitem>
 342       </varlistentry>
 343     </variablelist>
 344
 345     <variablelist>
 346       <varlistentry>
 347         <term>SysV init scripts directory</term>
 348
 349         <listitem><para>The location of the SysV init script directory
 350         varies between distributions. If systemd cannot find a native
 351         unit file for a requested service, it will look for a SysV
 352         init script of the same name (with the
 353         <filename>.service</filename> suffix
 354         removed).</para></listitem>
 355       </varlistentry>
 356     </variablelist>
 357
 358     <variablelist>
 359       <varlistentry>
 360         <term>SysV runlevel link farm directory</term>
 361
 362         <listitem><para>The location of the SysV runlevel link farm
 363         directory varies between distributions. systemd will take the
 364         link farm into account when figuring out whether a service
 365         shall be enabled. Note that a service unit with a native unit
 366         configuration file cannot be started by activating it in the
 367         SysV runlevel link farm.</para></listitem>
 368       </varlistentry>
 369     </variablelist>
 370   </refsect1>
 371
 372   <refsect1>
 373     <title>Signals</title>
 374
 375     <variablelist>
 376       <varlistentry>
 377         <term><constant>SIGTERM</constant></term>
 378
 379         <listitem><para>Upon receiving this signal the systemd system
 380         manager serializes its state, reexecutes itself and
 381         deserializes the saved state again. This is mostly equivalent
 382         to <command>systemctl daemon-reexec</command>.</para>
 383
 384         <para>systemd user managers will start the
 385         <filename>exit.target</filename> unit when this signal is
 386         received. This is mostly equivalent to <command>systemctl
 387         --user start exit.target
 388         --job-mode=replace-irreversibly</command>.</para></listitem>
 389       </varlistentry>
 390
 391       <varlistentry>
 392         <term><constant>SIGINT</constant></term>
 393
 394         <listitem><para>Upon receiving this signal the systemd system manager will start the
 395         <filename>ctrl-alt-del.target</filename> unit. This is mostly equivalent to
 396         <command>systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly</command>. If
 397         this signal is received more than 7 times per 2s, an immediate reboot is triggered. Note
 398         that pressing
 399         <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> on the
 400         console will trigger this signal. Hence, if a reboot is hanging, pressing
 401         <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>Del</keycap></keycombo> more than
 402         7 times in 2 seconds is a relatively safe way to trigger an immediate reboot.</para>
 403
 404         <para>systemd user managers treat this signal the same way as
 405         <constant>SIGTERM</constant>.</para></listitem>
 406       </varlistentry>
 407
 408       <varlistentry>
 409         <term><constant>SIGWINCH</constant></term>
 410
 411         <listitem><para>When this signal is received the systemd
 412         system manager will start the
 413         <filename>kbrequest.target</filename> unit. This is mostly
 414         equivalent to <command>systemctl start
 415         kbrequest.target</command>.</para>
 416
 417         <para>This signal is ignored by systemd user
 418         managers.</para></listitem>
 419       </varlistentry>
 420
 421       <varlistentry>
 422         <term><constant>SIGPWR</constant></term>
 423
 424         <listitem><para>When this signal is received the systemd
 425         manager will start the <filename>sigpwr.target</filename>
 426         unit. This is mostly equivalent to <command>systemctl start
 427         sigpwr.target</command>.</para></listitem>
 428       </varlistentry>
 429
 430       <varlistentry>
 431         <term><constant>SIGUSR1</constant></term>
 432
 433         <listitem><para>When this signal is received the systemd
 434         manager will try to reconnect to the D-Bus
 435         bus.</para></listitem>
 436       </varlistentry>
 437
 438       <varlistentry>
 439         <term><constant>SIGUSR2</constant></term>
 440
 441         <listitem><para>When this signal is received the systemd
 442         manager will log its complete state in human-readable form.
 443         The data logged is the same as printed by
 444         <command>systemd-analyze dump</command>.</para></listitem>
 445       </varlistentry>
 446
 447       <varlistentry>
 448         <term><constant>SIGHUP</constant></term>
 449
 450         <listitem><para>Reloads the complete daemon configuration.
 451         This is mostly equivalent to <command>systemctl
 452         daemon-reload</command>.</para></listitem>
 453       </varlistentry>
 454
 455       <varlistentry>
 456         <term><constant>SIGRTMIN+0</constant></term>
 457
 458         <listitem><para>Enters default mode, starts the
 459         <filename>default.target</filename> unit. This is mostly
 460         equivalent to <command>systemctl isolate
 461         default.target</command>.</para></listitem>
 462       </varlistentry>
 463
 464       <varlistentry>
 465         <term><constant>SIGRTMIN+1</constant></term>
 466
 467         <listitem><para>Enters rescue mode, starts the
 468         <filename>rescue.target</filename> unit. This is mostly
 469         equivalent to <command>systemctl isolate
 470         rescue.target</command>.</para></listitem>
 471       </varlistentry>
 472
 473       <varlistentry>
 474         <term><constant>SIGRTMIN+2</constant></term>
 475
 476         <listitem><para>Enters emergency mode, starts the
 477         <filename>emergency.service</filename> unit. This is mostly
 478         equivalent to <command>systemctl isolate
 479         emergency.service</command>.</para></listitem>
 480       </varlistentry>
 481
 482       <varlistentry>
 483         <term><constant>SIGRTMIN+3</constant></term>
 484
 485         <listitem><para>Halts the machine, starts the
 486         <filename>halt.target</filename> unit. This is mostly
 487         equivalent to <command>systemctl start halt.target
 488         --job-mode=replace-irreversibly</command>.</para>
 489         </listitem>
 490       </varlistentry>
 491
 492       <varlistentry>
 493         <term><constant>SIGRTMIN+4</constant></term>
 494
 495         <listitem><para>Powers off the machine, starts the
 496         <filename>poweroff.target</filename> unit. This is mostly
 497         equivalent to <command>systemctl start poweroff.target
 498         --job-mode=replace-irreversibly</command>.</para>
 499         </listitem>
 500       </varlistentry>
 501
 502       <varlistentry>
 503         <term><constant>SIGRTMIN+5</constant></term>
 504
 505         <listitem><para>Reboots the machine, starts the
 506         <filename>reboot.target</filename> unit. This is mostly
 507         equivalent to <command>systemctl start reboot.target
 508         --job-mode=replace-irreversibly</command>.</para>
 509         </listitem>
 510       </varlistentry>
 511
 512       <varlistentry>
 513         <term><constant>SIGRTMIN+6</constant></term>
 514
 515         <listitem><para>Reboots the machine via kexec, starts the
 516         <filename>kexec.target</filename> unit. This is mostly
 517         equivalent to <command>systemctl start kexec.target
 518         --job-mode=replace-irreversibly</command>.</para>
 519         </listitem>
 520       </varlistentry>
 521
 522       <varlistentry>
 523         <term><constant>SIGRTMIN+7</constant></term>
 524
 525         <listitem><para>Reboots userspace, starts the <filename>soft-reboot.target</filename> unit. This is
 526         mostly equivalent to <command>systemctl start soft-reboot.target
 527         --job-mode=replace-irreversibly</command>.</para>
 528
 529         <xi:include href="version-info.xml" xpointer="v254"/>
 530         </listitem>
 531       </varlistentry>
 532
 533       <varlistentry>
 534         <term><constant>SIGRTMIN+13</constant></term>
 535
 536         <listitem><para>Immediately halts the machine.</para></listitem>
 537       </varlistentry>
 538
 539       <varlistentry>
 540         <term><constant>SIGRTMIN+14</constant></term>
 541
 542         <listitem><para>Immediately powers off the machine.</para></listitem>
 543       </varlistentry>
 544
 545       <varlistentry>
 546         <term><constant>SIGRTMIN+15</constant></term>
 547
 548         <listitem><para>Immediately reboots the machine.</para></listitem>
 549       </varlistentry>
 550
 551       <varlistentry>
 552         <term><constant>SIGRTMIN+16</constant></term>
 553
 554         <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
 555       </varlistentry>
 556
 557       <varlistentry>
 558         <term><constant>SIGRTMIN+17</constant></term>
 559
 560         <listitem><para>Immediately reboots the userspace.</para>
 561
 562         <xi:include href="version-info.xml" xpointer="v254"/></listitem>
 563       </varlistentry>
 564
 565       <varlistentry>
 566         <term><constant>SIGRTMIN+20</constant></term>
 567
 568         <listitem><para>Enables display of status messages on the
 569         console, as controlled via
 570         <varname>systemd.show_status=1</varname> on the kernel command
 571         line.</para></listitem>
 572       </varlistentry>
 573
 574       <varlistentry>
 575         <term><constant>SIGRTMIN+21</constant></term>
 576
 577         <listitem><para>Disables display of
 578         status messages on the console, as
 579         controlled via
 580         <varname>systemd.show_status=0</varname>
 581         on the kernel command
 582         line.</para></listitem>
 583       </varlistentry>
 584
 585       <varlistentry>
 586         <term><constant>SIGRTMIN+22</constant></term>
 587
 588         <listitem><para>Sets the service manager's log level to <literal>debug</literal>, in a fashion equivalent to
 589         <varname>systemd.log_level=debug</varname> on the kernel command line.</para></listitem>
 590       </varlistentry>
 591
 592       <varlistentry>
 593         <term><constant>SIGRTMIN+23</constant></term>
 594
 595         <listitem><para>Restores the log level to its configured value. The configured value is derived from – in order
 596         of priority – the value specified with <varname>systemd.log-level=</varname> on the kernel command line, or the
 597         value specified with <option>LogLevel=</option> in the configuration file, or the built-in default of
 598         <literal>info</literal>.</para>
 599
 600         <xi:include href="version-info.xml" xpointer="v239"/></listitem>
 601       </varlistentry>
 602
 603       <varlistentry>
 604         <term><constant>SIGRTMIN+24</constant></term>
 605
 606         <listitem><para>Immediately exits the manager (only available
 607         for --user instances).</para>
 608
 609         <xi:include href="version-info.xml" xpointer="v195"/></listitem>
 610       </varlistentry>
 611
 612       <varlistentry>
 613         <term><constant>SIGRTMIN+25</constant></term>
 614
 615         <listitem><para>Upon receiving this signal the systemd manager will reexecute itself. This
 616         is mostly equivalent to <command>systemctl daemon-reexec</command> except that it will be
 617         done asynchronously.</para>
 618
 619         <para>The systemd system manager treats this signal the same way as
 620         <constant>SIGTERM</constant>.</para>
 621
 622         <xi:include href="version-info.xml" xpointer="v250"/></listitem>
 623       </varlistentry>
 624
 625       <varlistentry>
 626         <term><constant>SIGRTMIN+26</constant></term>
 627
 628         <listitem><para>Restores the log target to its configured value. The configured value is derived from – in
 629         order of priority – the value specified with <varname>systemd.log-target=</varname> on the kernel command line,
 630         or the value specified with <option>LogTarget=</option> in the configuration file, or the built-in
 631         default.</para>
 632
 633         <xi:include href="version-info.xml" xpointer="v239"/></listitem>
 634       </varlistentry>
 635
 636       <varlistentry>
 637         <term><constant>SIGRTMIN+27</constant></term>
 638         <term><constant>SIGRTMIN+28</constant></term>
 639
 640         <listitem><para>Sets the log target to <literal>console</literal> on <constant>SIGRTMIN+27</constant> (or
 641         <literal>kmsg</literal> on <constant>SIGRTMIN+28</constant>), in a fashion equivalent to
 642         <varname>systemd.log_target=console</varname> (or <varname>systemd.log_target=kmsg</varname> on
 643         <constant>SIGRTMIN+28</constant>) on the kernel command line.</para>
 644
 645         <xi:include href="version-info.xml" xpointer="v239"/></listitem>
 646       </varlistentry>
 647     </variablelist>
 648   </refsect1>
 649
 650   <refsect1>
 651     <title>Environment</title>
 652
 653     <para>The environment block for the system manager is initially set by the kernel. (In particular,
 654     <literal>key=value</literal> assignments on the kernel command line are turned into environment
 655     variables for PID 1). For the user manager, the system manager sets the environment as described in the
 656     "Environment Variables in Spawned Processes" section of
 657     <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>. The
 658     <varname>DefaultEnvironment=</varname> setting in the system manager applies to all services including
 659     <filename>user@.service</filename>. Additional entries may be configured (as for any other service)
 660     through the <varname>Environment=</varname> and <varname>EnvironmentFile=</varname> settings for
 661     <filename>user@.service</filename> (see
 662     <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>). Also,
 663     additional environment variables may be set through the <varname>ManagerEnvironment=</varname> setting in
 664     <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 665     and
 666     <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 667     </para>
 668
 669     <para>Some of the variables understood by <command>systemd</command>:</para>
 670
 671     <variablelist class='environment-variables'>
 672       <varlistentry>
 673         <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
 674         <listitem><xi:include href="common-variables.xml" xpointer="log-level-body" />
 675
 676         <para>This can be overridden with <option>--log-level=</option>.</para></listitem>
 677       </varlistentry>
 678
 679       <varlistentry>
 680         <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
 681         <listitem><xi:include href="common-variables.xml" xpointer="log-color-body" />
 682
 683         <para>This can be overridden with <option>--log-color=</option>.</para></listitem>
 684       </varlistentry>
 685
 686       <varlistentry>
 687         <term><varname>$SYSTEMD_LOG_TIME</varname></term>
 688         <listitem><xi:include href="common-variables.xml" xpointer="log-time-body" />
 689
 690         <para>This can be overridden with <option>--log-time=</option>.</para>
 691
 692         <xi:include href="version-info.xml" xpointer="v246"/></listitem>
 693       </varlistentry>
 694
 695       <varlistentry>
 696         <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
 697         <listitem><xi:include href="common-variables.xml" xpointer="log-location-body" />
 698
 699         <para>This can be overridden with <option>--log-location=</option>.</para></listitem>
 700       </varlistentry>
 701
 702       <varlistentry>
 703         <term><varname>$SYSTEMD_LOG_TID</varname></term>
 704         <listitem><xi:include href="common-variables.xml" xpointer="log-tid-body" />
 705
 706         <xi:include href="version-info.xml" xpointer="v247"/></listitem>
 707       </varlistentry>
 708
 709       <varlistentry>
 710         <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
 711         <listitem><xi:include href="common-variables.xml" xpointer="log-target-body" />
 712
 713         <para>This can be overridden with <option>--log-target=</option>.</para></listitem>
 714       </varlistentry>
 715
 716       <varlistentry>
 717         <term><varname>$SYSTEMD_LOG_RATELIMIT_KMSG</varname></term>
 718         <listitem><xi:include href="common-variables.xml" xpointer="log-ratelimit-kmsg-body" />
 719
 720         <xi:include href="version-info.xml" xpointer="v254"/></listitem>
 721       </varlistentry>
 722
 723       <varlistentry>
 724         <term><varname>$XDG_CONFIG_HOME</varname></term>
 725         <term><varname>$XDG_CONFIG_DIRS</varname></term>
 726         <term><varname>$XDG_DATA_HOME</varname></term>
 727         <term><varname>$XDG_DATA_DIRS</varname></term>
 728
 729         <listitem><para>The systemd user manager uses these variables
 730         in accordance to the <ulink
 731         url="https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 732         Base Directory specification</ulink> to find its
 733         configuration.</para></listitem>
 734       </varlistentry>
 735
 736       <varlistentry>
 737         <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
 738         <term><varname>$SYSTEMD_GENERATOR_PATH</varname></term>
 739         <term><varname>$SYSTEMD_ENVIRONMENT_GENERATOR_PATH</varname></term>
 740
 741         <listitem><para>Controls where systemd looks for unit files and
 742         generators.</para>
 743         <para>These variables may contain a list of paths, separated by colons
 744         (<literal>:</literal>). When set, if the list ends with an empty
 745         component (<literal>...:</literal>), this list is prepended to the
 746         usual set of paths. Otherwise, the specified list replaces the usual
 747         set of paths.
 748         </para></listitem>
 749       </varlistentry>
 750
 751       <xi:include href="common-variables.xml" xpointer="pager"/>
 752       <xi:include href="common-variables.xml" xpointer="less"/>
 753       <xi:include href="common-variables.xml" xpointer="lesscharset"/>
 754       <xi:include href="common-variables.xml" xpointer="lesssecure"/>
 755       <xi:include href="common-variables.xml" xpointer="colors"/>
 756       <xi:include href="common-variables.xml" xpointer="urlify"/>
 757
 758       <varlistentry>
 759         <term><varname>$LISTEN_PID</varname></term>
 760         <term><varname>$LISTEN_FDS</varname></term>
 761         <term><varname>$LISTEN_FDNAMES</varname></term>
 762
 763         <listitem><para>Set by systemd for supervised processes during
 764         socket-based activation. See
 765         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 766         for more information.</para></listitem>
 767       </varlistentry>
 768
 769       <varlistentry>
 770         <term><varname>$NOTIFY_SOCKET</varname></term>
 771
 772         <listitem><para>Set by systemd for supervised processes for
 773         status and start-up completion notification. See
 774         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 775         for more information.</para></listitem>
 776       </varlistentry>
 777     </variablelist>
 778
 779     <para>For further environment variables understood by systemd and its various components, see <ulink
 780     url="https://systemd.io/ENVIRONMENT">Known Environment Variables</ulink>.</para>
 781   </refsect1>
 782
 783   <refsect1>
 784     <title>Kernel Command Line</title>
 785
 786     <para>When run as the system instance, systemd parses a number of options listed below. They can be
 787     specified as kernel command line arguments which are parsed from a number of sources depending on the
 788     environment in which systemd is executed. If run inside a Linux container, these options are parsed from
 789     the command line arguments passed to systemd itself, next to any of the command line options listed in
 790     the Options section above. If run outside of Linux containers, these arguments are parsed from
 791     <filename>/proc/cmdline</filename> and from the <literal>SystemdOptions</literal> EFI variable
 792     (on EFI systems) instead. Options from <filename>/proc/cmdline</filename> have higher priority.</para>
 793
 794     <para>Note: use of <literal>SystemdOptions</literal> is deprecated.</para>
 795
 796     <para>The following variables are understood:</para>
 797
 798     <variablelist class='kernel-commandline-options'>
 799       <varlistentry>
 800         <term><varname>systemd.unit=</varname></term>
 801         <term><varname>rd.systemd.unit=</varname></term>
 802
 803         <listitem><para>Overrides the unit to activate on boot.  Defaults to
 804         <filename>default.target</filename>. This may be used to temporarily boot into a different boot unit,
 805         for example <filename>rescue.target</filename> or <filename>emergency.service</filename>. See
 806         <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 807         for details about these units. The option prefixed with <literal>rd.</literal> is honored only in the
 808         initrd, while the one that is not prefixed only in the main system.</para></listitem>
 809       </varlistentry>
 810
 811       <varlistentry>
 812         <term><varname>systemd.dump_core</varname></term>
 813
 814         <listitem><para>Takes a boolean argument or enables the option if specified
 815         without an argument. If enabled, the systemd manager (PID 1) dumps core when
 816         it crashes. Otherwise, no core dump is created. Defaults to enabled.</para>
 817
 818         <xi:include href="version-info.xml" xpointer="v233"/>
 819         </listitem>
 820       </varlistentry>
 821
 822       <varlistentry>
 823         <term><varname>systemd.crash_chvt</varname></term>
 824
 825         <listitem><para>Takes a positive integer, or a boolean argument. Can be also specified without an
 826         argument, with the same effect as a positive boolean. If a positive integer (in the range 1–63) is
 827         specified, the system manager (PID 1) will activate the specified virtual terminal when it crashes.
 828         Defaults to disabled, meaning that no such switch is attempted. If set to enabled, the virtual
 829         terminal the kernel messages are written to is used instead.</para>
 830
 831         <xi:include href="version-info.xml" xpointer="v233"/></listitem>
 832       </varlistentry>
 833
 834       <varlistentry>
 835         <term><varname>systemd.crash_shell</varname></term>
 836
 837         <listitem><para>Takes a boolean argument or enables the option if specified
 838         without an argument. If enabled, the system manager (PID 1) spawns a shell
 839         when it crashes, after a 10s delay. Otherwise, no shell is spawned. Defaults
 840         to disabled, for security reasons, as the shell is not protected by password
 841         authentication.</para>
 842
 843         <xi:include href="version-info.xml" xpointer="v233"/></listitem>
 844       </varlistentry>
 845
 846       <varlistentry>
 847         <term><varname>systemd.crash_reboot</varname></term>
 848
 849         <listitem><para>Takes a boolean argument or enables the option if specified
 850         without an argument. If enabled, the system manager (PID 1) will reboot the
 851         machine automatically when it crashes, after a 10s delay.  Otherwise, the
 852         system will hang indefinitely. Defaults to disabled, in order to avoid a
 853         reboot loop. If combined with <varname>systemd.crash_shell</varname>, the
 854         system is rebooted after the shell exits.</para>
 855
 856         <xi:include href="version-info.xml" xpointer="v227"/></listitem>
 857       </varlistentry>
 858
 859       <varlistentry>
 860         <term><varname>systemd.confirm_spawn</varname></term>
 861
 862         <listitem><para>Takes a boolean argument or a path to the virtual console
 863         where the confirmation messages should be emitted. Can be also specified
 864         without an argument, with the same effect as a positive boolean. If enabled,
 865         the system manager (PID 1) asks for confirmation when spawning processes
 866         using <option>/dev/console</option>. If a path or a console name (such as
 867         <literal>ttyS0</literal>) is provided, the virtual console pointed to by this
 868         path or described by the give name will be used instead. Defaults to disabled.
 869         </para>
 870
 871         <xi:include href="version-info.xml" xpointer="v233"/></listitem>
 872       </varlistentry>
 873
 874       <varlistentry>
 875         <term><varname>systemd.service_watchdogs=</varname></term>
 876
 877         <listitem><para>Takes a boolean argument. If disabled, all service runtime
 878         watchdogs (<option>WatchdogSec=</option>) and emergency actions (e.g.
 879         <option>OnFailure=</option> or <option>StartLimitAction=</option>) are
 880         ignored by the system manager (PID 1); see
 881         <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 882         Defaults to enabled, i.e. watchdogs and failure actions are processed
 883         normally. The hardware watchdog is not affected by this
 884         option.</para>
 885
 886         <xi:include href="version-info.xml" xpointer="v237"/></listitem>
 887       </varlistentry>
 888
 889       <varlistentry>
 890         <term><varname>systemd.show_status</varname></term>
 891
 892         <listitem><para>Takes a boolean argument or the constants <constant>error</constant> and
 893         <constant>auto</constant>. Can be also specified without an argument, with the same effect as a
 894         positive boolean. If enabled, the systemd manager (PID 1) shows terse service status updates on the
 895         console during bootup. With <constant>error</constant>, only messages about failures are shown, but
 896         boot is otherwise quiet. <constant>auto</constant> behaves like <option>false</option> until there is
 897         a significant delay in boot. Defaults to enabled, unless <option>quiet</option> is passed as kernel
 898         command line option, in which case it defaults to <constant>error</constant>. If specified overrides
 899         the system manager configuration file option <option>ShowStatus=</option>, see
 900         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 901         </para>
 902
 903         <xi:include href="version-info.xml" xpointer="v233"/></listitem>
 904       </varlistentry>
 905
 906       <varlistentry>
 907         <term><varname>systemd.status_unit_format=</varname></term>
 908
 909         <listitem><para>Takes <option>name</option>, <option>description</option> or
 910         <option>combined</option> as the value. If <option>name</option>, the system manager will use unit
 911         names in status messages. If <option>combined</option>, the system manager will use unit names and
 912         description in status messages. When specified, overrides the system manager configuration file
 913         option <option>StatusUnitFormat=</option>, see
 914         <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 915         </para>
 916
 917         <xi:include href="version-info.xml" xpointer="v243"/></listitem>
 918       </varlistentry>
 919
 920       <varlistentry>
 921         <term><varname>systemd.log_color</varname></term>
 922         <term><varname>systemd.log_level=</varname></term>
 923         <term><varname>systemd.log_location</varname></term>
 924         <term><varname>systemd.log_target=</varname></term>
 925         <term><varname>systemd.log_time</varname></term>
 926         <term><varname>systemd.log_tid</varname></term>
 927         <term><varname>systemd.log_ratelimit_kmsg</varname></term>
 928
 929         <listitem><para>Controls log output, with the same effect as the
 930         <varname>$SYSTEMD_LOG_COLOR</varname>, <varname>$SYSTEMD_LOG_LEVEL</varname>,
 931         <varname>$SYSTEMD_LOG_LOCATION</varname>, <varname>$SYSTEMD_LOG_TARGET</varname>,
 932         <varname>$SYSTEMD_LOG_TIME</varname>, <varname>$SYSTEMD_LOG_TID</varname> and
 933         <varname>$SYSTEMD_LOG_RATELIMIT_KMSG</varname> environment variables described above.
 934         <varname>systemd.log_color</varname>, <varname>systemd.log_location</varname>,
 935         <varname>systemd.log_time</varname>, <varname>systemd.log_tid</varname> and
 936         <varname>systemd.log_ratelimit_kmsg</varname> can be specified without
 937         an argument, with the same effect as a positive boolean.</para></listitem>
 938       </varlistentry>
 939
 940       <varlistentry>
 941         <term><varname>systemd.default_standard_output=</varname></term>
 942         <term><varname>systemd.default_standard_error=</varname></term>
 943
 944         <listitem><para>Controls default standard output and error output for services and sockets. That is,
 945         controls the default for <option>StandardOutput=</option> and <option>StandardError=</option> (see
 946         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
 947         details). Takes one of <option>inherit</option>, <option>null</option>, <option>tty</option>,
 948         <option>journal</option>, <option>journal+console</option>, <option>kmsg</option>,
 949         <option>kmsg+console</option>. If the argument is omitted
 950         <varname>systemd.default-standard-output=</varname> defaults to <option>journal</option> and
 951         <varname>systemd.default-standard-error=</varname> to <option>inherit</option>.</para></listitem>
 952       </varlistentry>
 953
 954       <varlistentry>
 955         <term><varname>systemd.setenv=</varname></term>
 956
 957         <listitem><para>Takes a string argument in the form
 958         VARIABLE=VALUE. May be used to set default environment
 959         variables to add to forked child processes. May be used more
 960         than once to set multiple variables.</para></listitem>
 961       </varlistentry>
 962
 963       <varlistentry>
 964         <term><varname>systemd.machine_id=</varname></term>
 965
 966         <listitem><para>Takes a 32 character hex value to be
 967         used for setting the machine-id. Intended mostly for
 968         network booting where the same machine-id is desired
 969         for every boot.</para>
 970
 971         <xi:include href="version-info.xml" xpointer="v229"/></listitem>
 972       </varlistentry>
 973
 974       <varlistentry>
 975         <term><varname>systemd.set_credential=</varname></term>
 976         <term><varname>systemd.set_credential_binary=</varname></term>
 977
 978         <listitem><para>Sets a system credential, which can then be propagated to system services using the
 979         <varname>ImportCredential=</varname> or <varname>LoadCredential=</varname> setting, see
 980         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
 981         details. Takes a pair of credential name and value, separated by a colon. The
 982         <varname>systemd.set_credential=</varname> parameter expects the credential value in literal text
 983         form, the <varname>systemd.set_credential_binary=</varname> parameter takes binary data encoded in
 984         Base64. Note that the kernel command line is typically accessible by unprivileged programs in
 985         <filename>/proc/cmdline</filename>. Thus, this mechanism is not suitable for transferring sensitive
 986         data. Use it only for data that is not sensitive (e.g. public keys/certificates, rather than private
 987         keys), or in testing/debugging environments.</para>
 988
 989         <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
 990         Credentials</ulink> documentation.</para>
 991
 992         <xi:include href="version-info.xml" xpointer="v251"/></listitem>
 993       </varlistentry>
 994
 995       <varlistentry>
 996         <term><varname>systemd.import_credentials=</varname></term>
 997
 998         <listitem><para>Takes a boolean argument. If false disables importing credentials from the kernel
 999         command line, the DMI/SMBIOS OEM string table, the qemu_fw_cfg subsystem or the EFI kernel
1000         stub.</para>
1001
1002         <xi:include href="version-info.xml" xpointer="v251"/></listitem>
1003       </varlistentry>
1004
1005       <varlistentry>
1006         <term><varname>quiet</varname></term>
1007
1008         <listitem><para>Turn off status output at boot, much like
1009         <varname>systemd.show_status=no</varname> would. Note that
1010         this option is also read by the kernel itself and disables
1011         kernel log output. Passing this option hence turns off the
1012         usual output from both the system manager and the kernel.
1013         </para>
1014
1015         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1016       </varlistentry>
1017
1018       <varlistentry>
1019         <term><varname>debug</varname></term>
1020
1021         <listitem><para>Turn on debugging output. This is equivalent
1022         to <varname>systemd.log_level=debug</varname>. Note that this
1023         option is also read by the kernel itself and enables kernel
1024         debug output. Passing this option hence turns on the debug
1025         output from both the system manager and the
1026         kernel.</para>
1027
1028         <xi:include href="version-info.xml" xpointer="v205"/></listitem>
1029       </varlistentry>
1030
1031       <varlistentry>
1032         <term><varname>emergency</varname></term>
1033         <term><varname>rd.emergency</varname></term>
1034         <term><varname>-b</varname></term>
1035
1036         <listitem><para>Boot into emergency mode. This is equivalent
1037         to <varname>systemd.unit=emergency.target</varname> or
1038         <varname>rd.systemd.unit=emergency.target</varname>, respectively, and
1039         provided for compatibility reasons and to be easier to type.</para>
1040
1041         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1042       </varlistentry>
1043
1044       <varlistentry>
1045         <term><varname>rescue</varname></term>
1046         <term><varname>rd.rescue</varname></term>
1047         <term><varname>single</varname></term>
1048         <term><varname>s</varname></term>
1049         <term><varname>S</varname></term>
1050         <term><varname>1</varname></term>
1051
1052         <listitem><para>Boot into rescue mode. This is equivalent to
1053         <varname>systemd.unit=rescue.target</varname> or
1054         <varname>rd.systemd.unit=rescue.target</varname>, respectively, and
1055         provided for compatibility reasons and to be easier to type.</para>
1056
1057         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1058       </varlistentry>
1059
1060       <varlistentry>
1061         <term><varname>2</varname></term>
1062         <term><varname>3</varname></term>
1063         <term><varname>4</varname></term>
1064         <term><varname>5</varname></term>
1065
1066         <listitem><para>Boot into the specified legacy SysV runlevel.
1067         These are equivalent to
1068         <varname>systemd.unit=runlevel2.target</varname>,
1069         <varname>systemd.unit=runlevel3.target</varname>,
1070         <varname>systemd.unit=runlevel4.target</varname>, and
1071         <varname>systemd.unit=runlevel5.target</varname>,
1072         respectively, and provided for compatibility reasons and to be
1073         easier to type.</para>
1074
1075         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1076       </varlistentry>
1077
1078       <varlistentry>
1079         <term><varname>locale.LANG=</varname></term>
1080         <term><varname>locale.LANGUAGE=</varname></term>
1081         <term><varname>locale.LC_CTYPE=</varname></term>
1082         <term><varname>locale.LC_NUMERIC=</varname></term>
1083         <term><varname>locale.LC_TIME=</varname></term>
1084         <term><varname>locale.LC_COLLATE=</varname></term>
1085         <term><varname>locale.LC_MONETARY=</varname></term>
1086         <term><varname>locale.LC_MESSAGES=</varname></term>
1087         <term><varname>locale.LC_PAPER=</varname></term>
1088         <term><varname>locale.LC_NAME=</varname></term>
1089         <term><varname>locale.LC_ADDRESS=</varname></term>
1090         <term><varname>locale.LC_TELEPHONE=</varname></term>
1091         <term><varname>locale.LC_MEASUREMENT=</varname></term>
1092         <term><varname>locale.LC_IDENTIFICATION=</varname></term>
1093
1094         <listitem><para>Set the system locale to use. This overrides
1095         the settings in <filename>/etc/locale.conf</filename>. For
1096         more information, see
1097         <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1098         and
1099         <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1100         </para>
1101
1102         <xi:include href="version-info.xml" xpointer="v186"/></listitem>
1103       </varlistentry>
1104     </variablelist>
1105
1106     <para>For other kernel command line parameters understood by
1107     components of the core OS, please refer to
1108     <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1109   </refsect1>
1110
1111   <refsect1>
1112     <title>System credentials</title>
1113
1114     <para>During initialization the service manager will import credentials from various sources into the
1115     system's set of credentials, which can then be propagated into services and consumed by
1116     generators:</para>
1117
1118     <itemizedlist>
1119       <listitem><para>When the service manager first initializes it will read system credentials from SMBIOS
1120       Type 11 vendor strings
1121       <varname>io.systemd.credential:<replaceable>name</replaceable>=<replaceable>value</replaceable></varname>,
1122       and
1123       <varname>io.systemd.credential.binary:<replaceable>name</replaceable>=<replaceable>value</replaceable></varname>.</para></listitem>
1124
1125       <listitem><para>At the same time it will import credentials from QEMU <literal>fw_cfg</literal>. (Note
1126       that the SMBIOS mechanism is generally preferred, because it is faster and generic.)</para></listitem>
1127
1128       <listitem><para>Credentials may be passed via the kernel command line, using the
1129       <varname>systemd.set-credential=</varname> parameter, see above.</para></listitem>
1130
1131       <listitem><para>Credentials may be passed from the UEFI environment via
1132       <citerefentry><refentrytitle>systemd-stub</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
1133
1134       <listitem><para>When the service manager is invoked during the initrd → host transition it will import
1135       all files in <filename>/run/credentials/@initrd/</filename> as system credentials.</para></listitem>
1136     </itemizedlist>
1137
1138     <para>Invoke
1139     <citerefentry><refentrytitle>systemd-creds</refentrytitle><manvolnum>1</manvolnum></citerefentry> as
1140     follows to see the list of credentials passed into the system:</para>
1141
1142     <programlisting># systemd-creds --system list</programlisting>
1143
1144     <para>For further information see <ulink url="https://systemd.io/CREDENTIALS">System and Service
1145     Credentials</ulink> documentation.</para>
1146
1147     <para>The service manager when run as PID 1 consumes the following system credentials:</para>
1148
1149     <variablelist class='system-credentials'>
1150       <varlistentry>
1151         <term><varname>vmm.notify_socket</varname></term>
1152         <listitem>
1153           <para>Contains a <constant>AF_VSOCK</constant> or <constant>AF_UNIX</constant> address where to
1154           send a <constant>READY=1</constant> notification datagram when the system has finished booting. See
1155           <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry> for
1156           more information. Note that in case the hypervisor does not support <constant>SOCK_DGRAM</constant>
1157           over <constant>AF_VSOCK</constant>, <constant>SOCK_SEQPACKET</constant> will be tried instead. The
1158           credential payload for <constant>AF_VSOCK</constant> should be in the form
1159           <literal>vsock:CID:PORT</literal>.</para>
1160
1161           <para>This feature is useful for hypervisors/VMMs or other processes on the host to receive a
1162           notification via VSOCK when a virtual machine has finished booting.</para>
1163
1164           <xi:include href="version-info.xml" xpointer="v254"/>
1165         </listitem>
1166       </varlistentry>
1167
1168       <varlistentry>
1169         <term><varname>system.machine_id</varname></term>
1170         <listitem>
1171           <para>Takes a 128bit hexadecimal ID to initialize <filename>/etc/machine-id</filename> from, if the
1172           file is not set up yet. See
1173           <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry> for
1174           details.</para>
1175
1176         <xi:include href="version-info.xml" xpointer="v254"/>
1177         </listitem>
1178       </varlistentry>
1179     </variablelist>
1180   </refsect1>
1181
1182   <refsect1>
1183     <title>Options</title>
1184
1185     <para><command>systemd</command> is only very rarely invoked directly, since it is started early and is
1186     already running by the time users may interact with it. Normally, tools like
1187     <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry> are used to
1188     give commands to the manager. Since <command>systemd</command> is usually not invoked directly, the
1189     options listed below are mostly useful for debugging and special purposes.</para>
1190
1191     <refsect2>
1192       <title>Introspection and debugging options</title>
1193
1194       <para>Those options are used for testing and introspection, and <command>systemd</command> may
1195       be invoked with them at any time:</para>
1196
1197       <variablelist>
1198         <varlistentry>
1199           <term><option>--dump-configuration-items</option></term>
1200
1201           <listitem><para>Dump understood unit configuration items. This outputs a terse but complete list of
1202           configuration items understood in unit definition files.</para></listitem>
1203         </varlistentry>
1204
1205         <varlistentry>
1206           <term><option>--dump-bus-properties</option></term>
1207
1208           <listitem><para>Dump exposed bus properties. This outputs a terse but complete list of properties
1209           exposed on D-Bus.</para>
1210
1211           <xi:include href="version-info.xml" xpointer="v239"/></listitem>
1212         </varlistentry>
1213
1214         <varlistentry>
1215           <term><option>--test</option></term>
1216
1217           <listitem><para>Determine the initial start-up transaction (i.e. the list of jobs enqueued at
1218           start-up), dump it and exit — without actually executing any of the determined jobs. This option is
1219           useful for debugging only. Note that during regular service manager start-up additional units not
1220           shown by this operation may be started, because hardware, socket, bus or other kinds of activation
1221           might add additional jobs as the transaction is executed. Use <option>--system</option> to request
1222           the initial transaction of the system service manager (this is also the implied default), combine
1223           with <option>--user</option> to request the initial transaction of the per-user service manager
1224           instead.</para></listitem>
1225         </varlistentry>
1226
1227         <varlistentry>
1228           <term><option>--system</option></term>
1229           <term><option>--user</option></term>
1230
1231           <listitem><para>When used in conjunction with <option>--test</option>, selects whether to calculate
1232           the initial transaction for the system instance or for a per-user instance. These options have no
1233           effect when invoked without <option>--test</option>, as during regular
1234           (i.e. non-<option>--test</option>) invocations the service manager will automatically detect
1235           whether it shall operate in system or per-user mode, by checking whether the PID it is run as is 1
1236           or not. Note that it is not supported booting and maintaining a system with the service manager
1237           running in <option>--system</option> mode but with a PID other than 1.</para></listitem>
1238         </varlistentry>
1239
1240         <xi:include href="standard-options.xml" xpointer="help" />
1241         <xi:include href="standard-options.xml" xpointer="version" />
1242       </variablelist>
1243     </refsect2>
1244
1245     <refsect2>
1246       <title>Options that duplicate kernel command line settings</title>
1247
1248       <para>Those options correspond directly to options listed above in "Kernel Command Line". Both forms
1249       may be used equivalently for the system manager, but it is recommended to use the forms listed above in
1250       this context, because they are properly namespaced. When an option is specified both on the kernel
1251       command line and as a normal command line argument, the latter has higher precedence.</para>
1252
1253       <para>When <command>systemd</command> is used as a user manager, the kernel command line is ignored and
1254       only the options described below are understood. Nevertheless, <command>systemd</command> is usually
1255       started in this mode through the
1256       <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1257       service, which is shared between all users. It may be more convenient to use configuration files to
1258       modify settings (see
1259       <citerefentry><refentrytitle>systemd-user.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>),
1260       or environment variables. See the "Environment" section above for a discussion of how the environment
1261       block is set.</para>
1262
1263       <variablelist>
1264         <varlistentry>
1265           <term><option>--unit=</option></term>
1266
1267           <listitem><para>Set default unit to activate on startup. If not specified, defaults to
1268           <filename>default.target</filename>. See <varname>systemd.unit=</varname> above.</para></listitem>
1269         </varlistentry>
1270
1271         <varlistentry>
1272           <term><option>--dump-core</option></term>
1273
1274           <listitem><para>Enable core dumping on crash. This switch has no effect when running as user
1275           instance. Same as <varname>systemd.dump_core=</varname> above.</para></listitem>
1276         </varlistentry>
1277
1278         <varlistentry>
1279           <term><option>--crash-vt=</option><replaceable>VT</replaceable></term>
1280
1281           <listitem><para>Switch to a specific virtual console (VT) on crash. This switch has no effect when
1282           running as user instance. Same as <varname>systemd.crash_chvt=</varname> above (but not the
1283           different spelling!).</para>
1284
1285           <xi:include href="version-info.xml" xpointer="v227"/></listitem>
1286         </varlistentry>
1287
1288         <varlistentry>
1289           <term><option>--crash-shell</option></term>
1290
1291           <listitem><para>Run a shell on crash. This switch has no effect when running as user instance. See
1292           <varname>systemd.crash_shell=</varname> above.</para></listitem>
1293         </varlistentry>
1294
1295         <varlistentry>
1296           <term><option>--crash-reboot</option></term>
1297
1298           <listitem><para>Automatically reboot the system on crash. This switch has no effect when running as
1299           user instance. See <varname>systemd.crash_reboot</varname> above.</para>
1300
1301           <xi:include href="version-info.xml" xpointer="v227"/></listitem>
1302         </varlistentry>
1303
1304         <varlistentry>
1305           <term><option>--confirm-spawn</option></term>
1306
1307           <listitem><para>Ask for confirmation when spawning processes. This switch has no effect when run as
1308           user instance. See <varname>systemd.confirm_spawn</varname> above.</para></listitem>
1309         </varlistentry>
1310
1311         <varlistentry>
1312           <term><option>--show-status</option></term>
1313
1314           <listitem><para>Show terse unit status information on the console during boot-up and shutdown. See
1315           <varname>systemd.show_status</varname> above.</para>
1316
1317           <xi:include href="version-info.xml" xpointer="v244"/></listitem>
1318         </varlistentry>
1319
1320         <varlistentry>
1321           <term><option>--log-color</option></term>
1322
1323           <listitem><para>Highlight important log messages. See <varname>systemd.log_color</varname> above.
1324           </para>
1325
1326           <xi:include href="version-info.xml" xpointer="v244"/></listitem>
1327         </varlistentry>
1328
1329         <varlistentry>
1330           <term><option>--log-level=</option></term>
1331
1332           <listitem><para>Set log level. See <varname>systemd.log_level</varname> above.</para></listitem>
1333         </varlistentry>
1334
1335         <varlistentry>
1336           <term><option>--log-location</option></term>
1337
1338           <listitem><para>Include code location in log messages. See <varname>systemd.log_location</varname>
1339           above.</para>
1340
1341           <xi:include href="version-info.xml" xpointer="v244"/></listitem>
1342         </varlistentry>
1343
1344         <varlistentry>
1345           <term><option>--log-target=</option></term>
1346
1347           <listitem><para>Set log target. See <varname>systemd.log_target</varname> above.</para></listitem>
1348         </varlistentry>
1349
1350         <varlistentry>
1351           <term><option>--log-time=</option></term>
1352
1353           <listitem><para>Prefix console messages with timestamp. See <varname>systemd.log_time</varname> above.
1354           </para>
1355
1356           <xi:include href="version-info.xml" xpointer="v246"/></listitem>
1357         </varlistentry>
1358
1359         <varlistentry>
1360           <term><option>--machine-id=</option></term>
1361
1362           <listitem><para>Override the machine-id set on the hard drive. See
1363           <varname>systemd.machine_id=</varname> above.</para>
1364
1365           <xi:include href="version-info.xml" xpointer="v229"/></listitem>
1366         </varlistentry>
1367
1368         <varlistentry>
1369           <term><option>--service-watchdogs</option></term>
1370
1371           <listitem><para>Globally enable/disable all service watchdog timeouts and emergency actions. See
1372           <varname>systemd.service_watchdogs</varname> above.</para>
1373
1374           <xi:include href="version-info.xml" xpointer="v237"/></listitem>
1375         </varlistentry>
1376
1377         <varlistentry>
1378           <term><option>--default-standard-output=</option></term>
1379           <term><option>--default-standard-error=</option></term>
1380
1381           <listitem><para>Sets the default output or error output for all services and sockets,
1382           respectively. See <varname>systemd.default_standard_output=</varname> and
1383           <varname>systemd.default_standard_error=</varname> above.</para></listitem>
1384         </varlistentry>
1385       </variablelist>
1386     </refsect2>
1387   </refsect1>
1388
1389   <refsect1>
1390     <title>Sockets and FIFOs</title>
1391
1392     <variablelist>
1393       <varlistentry>
1394         <term><filename>/run/systemd/notify</filename></term>
1395
1396         <listitem><para>Daemon status notification socket. This is an
1397         <constant>AF_UNIX</constant> datagram socket and is used to
1398         implement the daemon notification logic as implemented by
1399         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1400
1401       </varlistentry>
1402
1403       <varlistentry>
1404         <term><filename>/run/systemd/private</filename></term>
1405
1406         <listitem><para>Used internally as communication channel
1407         between
1408         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1409         and the systemd process. This is an
1410         <constant>AF_UNIX</constant> stream socket. This interface is
1411         private to systemd and should not be used in external
1412         projects.</para></listitem>
1413       </varlistentry>
1414
1415       <varlistentry>
1416         <term><filename>/dev/initctl</filename></term>
1417
1418         <listitem><para>Limited compatibility support for the SysV
1419         client interface, as implemented by the
1420         <filename>systemd-initctl.service</filename> unit. This is a
1421         named pipe in the file system. This interface is obsolete and
1422         should not be used in new applications.</para></listitem>
1423       </varlistentry>
1424     </variablelist>
1425   </refsect1>
1426
1427   <refsect1>
1428       <title>History</title>
1429
1430       <variablelist>
1431         <varlistentry>
1432           <term>systemd 252</term>
1433           <listitem><para>Kernel command-line arguments <varname>systemd.unified_cgroup_hierarchy</varname>
1434           and <varname>systemd.legacy_systemd_cgroup_controller</varname> were deprecated. Please switch to
1435           the unified cgroup hierarchy.</para>
1436
1437           <xi:include href="version-info.xml" xpointer="v252"/></listitem>
1438         </varlistentry>
1439       </variablelist>
1440   </refsect1>
1441
1442   <refsect1>
1443     <title>See Also</title>
1444     <para>
1445       The <ulink url="https://systemd.io/">systemd Homepage</ulink>,
1446       <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1447       <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1448       <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1449       <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1450       <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1451       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1452       <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
1453       <citerefentry><refentrytitle>org.freedesktop.systemd1</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1454       <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1455       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1456       <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1457       <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1458       <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1459       <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1460     </para>
1461   </refsect1>
1462
1463 </refentry>