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