man/systemd.xml

   1 <?xml version='1.0'?> <!--*-nxml-*-->
   2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
   3   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
   4
   5 <!--
   6   This file is part of systemd.
   7
   8   Copyright 2010 Lennart Poettering
   9
  10   systemd is free software; you can redistribute it and/or modify it
  11   under the terms of the GNU Lesser General Public License as published by
  12   the Free Software Foundation; either version 2.1 of the License, or
  13   (at your option) any later version.
  14
  15   systemd is distributed in the hope that it will be useful, but
  16   WITHOUT ANY WARRANTY; without even the implied warranty of
  17   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
  18   Lesser General Public License for more details.
  19
  20   You should have received a copy of the GNU Lesser General Public License
  21   along with systemd; If not, see <http://www.gnu.org/licenses/>.
  22 -->
  23
  24 <refentry id="systemd"
  25     xmlns:xi="http://www.w3.org/2001/XInclude">
  26
  27   <refentryinfo>
  28     <title>systemd</title>
  29     <productname>systemd</productname>
  30
  31     <authorgroup>
  32       <author>
  33         <contrib>Developer</contrib>
  34         <firstname>Lennart</firstname>
  35         <surname>Poettering</surname>
  36         <email>lennart@poettering.net</email>
  37       </author>
  38     </authorgroup>
  39   </refentryinfo>
  40
  41   <refmeta>
  42     <refentrytitle>systemd</refentrytitle>
  43     <manvolnum>1</manvolnum>
  44   </refmeta>
  45
  46   <refnamediv>
  47     <refname>systemd</refname>
  48     <refname>init</refname>
  49     <refpurpose>systemd system and service manager</refpurpose>
  50   </refnamediv>
  51
  52   <refsynopsisdiv>
  53     <cmdsynopsis>
  54       <command>systemd <arg choice="opt" rep="repeat">OPTIONS</arg></command>
  55     </cmdsynopsis>
  56     <cmdsynopsis>
  57       <command>init <arg choice="opt" rep="repeat">OPTIONS</arg> <arg choice="req">COMMAND</arg></command>
  58     </cmdsynopsis>
  59   </refsynopsisdiv>
  60
  61   <refsect1>
  62     <title>Description</title>
  63
  64     <para>systemd is a system and service manager for Linux operating
  65     systems. When run as first process on boot (as PID 1), it acts as
  66     init system that brings up and maintains userspace
  67     services.</para>
  68
  69     <para>For compatibility with SysV, if systemd is called as
  70     <command>init</command> and a PID that is not 1, it will execute
  71     <command>telinit</command> and pass all command line arguments
  72     unmodified. That means <command>init</command> and
  73     <command>telinit</command> are mostly equivalent when invoked from
  74     normal login sessions. See
  75     <citerefentry><refentrytitle>telinit</refentrytitle><manvolnum>8</manvolnum></citerefentry>
  76     for more information.</para>
  77
  78     <para>When run as a system instance, systemd interprets the
  79     configuration file <filename>system.conf</filename> and the files
  80     in <filename>system.conf.d</filename> directories; when run as a
  81     user instance, systemd interprets the configuration file
  82     <filename>user.conf</filename> and the files in
  83     <filename>user.conf.d</filename> directories. See
  84     <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
  85     for more information.</para>
  86   </refsect1>
  87
  88   <refsect1>
  89     <title>Options</title>
  90
  91     <para>The following options are understood:</para>
  92
  93     <variablelist>
  94       <varlistentry>
  95         <term><option>--test</option></term>
  96
  97         <listitem><para>Determine startup sequence, dump it and exit.
  98         This is an option useful for debugging only.</para></listitem>
  99       </varlistentry>
 100       <varlistentry>
 101         <term><option>--dump-configuration-items</option></term>
 102
 103         <listitem><para>Dump understood unit configuration items. This
 104         outputs a terse but complete list of configuration items
 105         understood in unit definition files.</para></listitem>
 106       </varlistentry>
 107       <varlistentry>
 108         <term><option>--unit=</option></term>
 109
 110         <listitem><para>Set default unit to activate on startup. If
 111         not specified, defaults to
 112         <filename>default.target</filename>.</para></listitem>
 113       </varlistentry>
 114       <varlistentry>
 115         <term><option>--system</option></term>
 116         <term><option>--user</option></term>
 117
 118         <listitem><para>For <option>--system</option>, tell systemd to
 119         run a system instance, even if the process ID is not 1, i.e.
 120         systemd is not run as init process. <option>--user</option>
 121         does the opposite, running a user instance even if the process
 122         ID is 1. Normally it should not be necessary to pass these
 123         options, as systemd automatically detects the mode it is
 124         started in. These options are hence of little use except for
 125         debugging. Note that it is not supported booting and
 126         maintaining a full system with systemd running in
 127         <option>--system</option> mode, but PID not 1. In practice,
 128         passing <option>--system</option> explicitly is only useful in
 129         conjunction with <option>--test</option>.</para></listitem>
 130       </varlistentry>
 131       <varlistentry>
 132         <term><option>--dump-core</option></term>
 133
 134         <listitem><para>Dump core on crash. This switch has no effect
 135         when run as user instance.</para></listitem>
 136       </varlistentry>
 137       <varlistentry>
 138         <term><option>--crash-shell</option></term>
 139
 140         <listitem><para>Run shell on
 141         crash. This switch has no effect when
 142         run as user
 143         instance.</para></listitem>
 144       </varlistentry>
 145       <varlistentry>
 146         <term><option>--confirm-spawn</option></term>
 147
 148         <listitem><para>Ask for confirmation when spawning processes.
 149         This switch has no effect when run as user
 150         instance.</para></listitem>
 151       </varlistentry>
 152       <varlistentry>
 153         <term><option>--show-status=</option></term>
 154
 155         <listitem><para>Show terse service status information while
 156         booting. This switch has no effect when run as user instance.
 157         Takes a boolean argument which may be omitted which is
 158         interpreted as <option>true</option>.</para></listitem>
 159       </varlistentry>
 160       <varlistentry>
 161         <term><option>--log-target=</option></term>
 162
 163         <listitem><para>Set log target. Argument must be one of
 164         <option>console</option>,
 165         <option>journal</option>,
 166         <option>kmsg</option>,
 167         <option>journal-or-kmsg</option>,
 168         <option>null</option>.</para></listitem>
 169       </varlistentry>
 170       <varlistentry>
 171         <term><option>--log-level=</option></term>
 172
 173         <listitem><para>Set log level. As
 174         argument this accepts a numerical log
 175         level or the well-known <citerefentry project='man-pages'><refentrytitle>syslog</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 176         symbolic names (lowercase):
 177         <option>emerg</option>,
 178         <option>alert</option>,
 179         <option>crit</option>,
 180         <option>err</option>,
 181         <option>warning</option>,
 182         <option>notice</option>,
 183         <option>info</option>,
 184         <option>debug</option>.</para></listitem>
 185       </varlistentry>
 186       <varlistentry>
 187         <term><option>--log-color=</option></term>
 188
 189         <listitem><para>Highlight important log messages. Argument is
 190         a boolean value. If the argument is omitted, it defaults to
 191         <option>true</option>.</para></listitem>
 192       </varlistentry>
 193       <varlistentry>
 194         <term><option>--log-location=</option></term>
 195
 196         <listitem><para>Include code location in log messages. This is
 197         mostly relevant for debugging purposes. Argument is a boolean
 198         value. If the argument is omitted it defaults to
 199         <option>true</option>.</para></listitem>
 200       </varlistentry>
 201       <varlistentry>
 202         <term><option>--default-standard-output=</option></term>
 203         <term><option>--default-standard-error=</option></term>
 204
 205         <listitem><para>Sets the default output or error output for
 206         all services and sockets, respectively. That is, controls the
 207         default for <option>StandardOutput=</option> and
 208         <option>StandardError=</option> (see
 209         <citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 210         for details). Takes one of
 211         <option>inherit</option>,
 212         <option>null</option>,
 213         <option>tty</option>,
 214         <option>journal</option>,
 215         <option>journal+console</option>,
 216         <option>syslog</option>,
 217         <option>syslog+console</option>,
 218         <option>kmsg</option>,
 219         <option>kmsg+console</option>.  If the
 220         argument is omitted
 221         <option>--default-standard-output=</option> defaults to
 222         <option>journal</option> and
 223         <option>--default-standard-error=</option> to
 224         <option>inherit</option>.</para></listitem>
 225       </varlistentry>
 226
 227       <xi:include href="standard-options.xml" xpointer="help" />
 228       <xi:include href="standard-options.xml" xpointer="version" />
 229     </variablelist>
 230   </refsect1>
 231
 232   <refsect1>
 233     <title>Concepts</title>
 234
 235     <para>systemd provides a dependency system between various
 236     entities called "units" of 12 different types. Units encapsulate
 237     various objects that are relevant for system boot-up and
 238     maintenance. The majority of units are configured in unit
 239     configuration files, whose syntax and basic set of options is
 240     described in
 241     <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 242     however some are created automatically from other configuration,
 243     dynamically from system state or programmatically at runtime.
 244     Units may be "active" (meaning started, bound, plugged in, ...,
 245     depending on the unit type, see below), or "inactive" (meaning
 246     stopped, unbound, unplugged, ...), as well as in the process of
 247     being activated or deactivated, i.e. between the two states (these
 248     states are called "activating", "deactivating"). A special
 249     "failed" state is available as well, which is very similar to
 250     "inactive" and is entered when the service failed in some way
 251     (process returned error code on exit, or crashed, or an operation
 252     timed out). If this state is entered, the cause will be logged,
 253     for later reference. Note that the various unit types may have a
 254     number of additional substates, which are mapped to the five
 255     generalized unit states described here.</para>
 256
 257     <para>The following unit types are available:</para>
 258
 259     <orderedlist>
 260       <listitem><para>Service units, which start and control daemons
 261       and the processes they consist of. For details see
 262       <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 263
 264       <listitem><para>Socket units, which encapsulate local IPC or
 265       network sockets in the system, useful for socket-based
 266       activation. For details about socket units see
 267       <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
 268       for details on socket-based activation and other forms of
 269       activation, see
 270       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para></listitem>
 271
 272       <listitem><para>Target units are useful to group units, or
 273       provide well-known synchronization points during boot-up, see
 274       <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 275
 276       <listitem><para>Device units expose kernel devices in systemd
 277       and may be used to implement device-based activation. For
 278       details see
 279       <citerefentry><refentrytitle>systemd.device</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 280
 281       <listitem><para>Mount units control mount points in the file
 282       system, for details see
 283       <citerefentry><refentrytitle>systemd.mount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 284
 285       <listitem><para>Automount units provide automount capabilities,
 286       for on-demand mounting of file systems as well as parallelized
 287       boot-up. See
 288       <citerefentry><refentrytitle>systemd.automount</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 289
 290       <listitem><para>Snapshot units can be used to temporarily save
 291       the state of the set of systemd units, which later may be
 292       restored by activating the saved snapshot unit. For more
 293       information see
 294       <citerefentry><refentrytitle>systemd.snapshot</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 295
 296       <listitem><para>Timer units are useful for triggering activation
 297       of other units based on timers. You may find details in
 298       <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 299
 300       <listitem><para>Swap units are very similar to mount units and
 301       encapsulate memory swap partitions or files of the operating
 302       system. They are described in
 303       <citerefentry><refentrytitle>systemd.swap</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 304
 305       <listitem><para>Path units may be used to activate other
 306       services when file system objects change or are modified. See
 307       <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 308
 309       <listitem><para>Slice units may be used to group units which
 310       manage system processes (such as service and scope units) in a
 311       hierarchical tree for resource management purposes. See
 312       <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 313
 314       <listitem><para>Scope units are similar to service units, but
 315       manage foreign processes instead of starting them as well. See
 316       <citerefentry><refentrytitle>systemd.scope</refentrytitle><manvolnum>5</manvolnum></citerefentry>.</para></listitem>
 317
 318     </orderedlist>
 319
 320     <para>Units are named as their configuration files. Some units
 321     have special semantics. A detailed list is available in
 322     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 323
 324     <para>systemd knows various kinds of dependencies, including
 325     positive and negative requirement dependencies (i.e.
 326     <varname>Requires=</varname> and <varname>Conflicts=</varname>) as
 327     well as ordering dependencies (<varname>After=</varname> and
 328     <varname>Before=</varname>). NB: ordering and requirement
 329     dependencies are orthogonal. If only a requirement dependency
 330     exists between two units (e.g. <filename>foo.service</filename>
 331     requires <filename>bar.service</filename>), but no ordering
 332     dependency (e.g. <filename>foo.service</filename> after
 333     <filename>bar.service</filename>) and both are requested to start,
 334     they will be started in parallel. It is a common pattern that both
 335     requirement and ordering dependencies are placed between two
 336     units. Also note that the majority of dependencies are implicitly
 337     created and maintained by systemd. In most cases, it should be
 338     unnecessary to declare additional dependencies manually, however
 339     it is possible to do this.</para>
 340
 341     <para>Application programs and units (via dependencies) may
 342     request state changes of units. In systemd, these requests are
 343     encapsulated as 'jobs' and maintained in a job queue. Jobs may
 344     succeed or can fail, their execution is ordered based on the
 345     ordering dependencies of the units they have been scheduled
 346     for.</para>
 347
 348     <para>On boot systemd activates the target unit
 349     <filename>default.target</filename> whose job is to activate
 350     on-boot services and other on-boot units by pulling them in via
 351     dependencies. Usually the unit name is just an alias (symlink) for
 352     either <filename>graphical.target</filename> (for fully-featured
 353     boots into the UI) or <filename>multi-user.target</filename> (for
 354     limited console-only boots for use in embedded or server
 355     environments, or similar; a subset of graphical.target). However,
 356     it is at the discretion of the administrator to configure it as an
 357     alias to any other target unit. See
 358     <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 359     for details about these target units.</para>
 360
 361     <para>Processes systemd spawns are placed in individual Linux
 362     control groups named after the unit which they belong to in the
 363     private systemd hierarchy. (see <ulink
 364     url="https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt">cgroups.txt</ulink>
 365     for more information about control groups, or short "cgroups").
 366     systemd uses this to effectively keep track of processes. Control
 367     group information is maintained in the kernel, and is accessible
 368     via the file system hierarchy (beneath
 369     <filename>/sys/fs/cgroup/systemd/</filename>), or in tools such as
 370     <citerefentry project='man-pages'><refentrytitle>systemd-cgls</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 371     or
 372     <citerefentry project='man-pages'><refentrytitle>ps</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 373     (<command>ps xawf -eo pid,user,cgroup,args</command> is
 374     particularly useful to list all processes and the systemd units
 375     they belong to.).</para>
 376
 377     <para>systemd is compatible with the SysV init system to a large
 378     degree: SysV init scripts are supported and simply read as an
 379     alternative (though limited) configuration file format. The SysV
 380     <filename>/dev/initctl</filename> interface is provided, and
 381     compatibility implementations of the various SysV client tools are
 382     available. In addition to that, various established Unix
 383     functionality such as <filename>/etc/fstab</filename> or the
 384     <filename>utmp</filename> database are supported.</para>
 385
 386     <para>systemd has a minimal transaction system: if a unit is
 387     requested to start up or shut down it will add it and all its
 388     dependencies to a temporary transaction. Then, it will verify if
 389     the transaction is consistent (i.e. whether the ordering of all
 390     units is cycle-free). If it is not, systemd will try to fix it up,
 391     and removes non-essential jobs from the transaction that might
 392     remove the loop. Also, systemd tries to suppress non-essential
 393     jobs in the transaction that would stop a running service. Finally
 394     it is checked whether the jobs of the transaction contradict jobs
 395     that have already been queued, and optionally the transaction is
 396     aborted then. If all worked out and the transaction is consistent
 397     and minimized in its impact it is merged with all already
 398     outstanding jobs and added to the run queue. Effectively this
 399     means that before executing a requested operation, systemd will
 400     verify that it makes sense, fixing it if possible, and only
 401     failing if it really cannot work.</para>
 402
 403     <para>Systemd contains native implementations of various tasks
 404     that need to be executed as part of the boot process. For example,
 405     it sets the hostname or configures the loopback network device. It
 406     also sets up and mounts various API file systems, such as
 407     <filename>/sys</filename> or <filename>/proc</filename>.</para>
 408
 409     <para>For more information about the concepts and
 410     ideas behind systemd, please refer to the
 411     <ulink url="http://0pointer.de/blog/projects/systemd.html">Original Design Document</ulink>.</para>
 412
 413     <para>Note that some but not all interfaces provided
 414     by systemd are covered by the
 415     <ulink url="http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise">Interface
 416     Stability Promise</ulink>.</para>
 417
 418     <para>Units may be generated dynamically at boot and system
 419     manager reload time, for example based on other configuration
 420     files or parameters passed on the kernel command line. For details see
 421     <citerefentry><refentrytitle>systemd.generator</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
 422
 423     <para>Systems which invoke systemd in a container or initrd
 424     environment should implement the
 425     <ulink url="http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface">Container Interface</ulink> or
 426     <ulink url="http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface">initrd Interface</ulink>
 427     specifications, respectively.</para>
 428   </refsect1>
 429
 430   <refsect1>
 431     <title>Directories</title>
 432
 433     <variablelist>
 434       <varlistentry>
 435         <term>System unit directories</term>
 436
 437         <listitem><para>The systemd system manager reads unit
 438         configuration from various directories. Packages that want to
 439         install unit files shall place them in the directory returned
 440         by <command>pkg-config systemd
 441         --variable=systemdsystemunitdir</command>. Other directories
 442         checked are <filename>/usr/local/lib/systemd/system</filename>
 443         and <filename>/usr/lib/systemd/system</filename>. User
 444         configuration always takes precedence. <command>pkg-config
 445         systemd --variable=systemdsystemconfdir</command> returns the
 446         path of the system configuration directory. Packages should
 447         alter the content of these directories only with the
 448         <command>enable</command> and <command>disable</command>
 449         commands of the
 450         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 451         tool. Full list of directories is provided in
 452         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 453         </para></listitem>
 454       </varlistentry>
 455     </variablelist>
 456
 457     <variablelist>
 458       <varlistentry>
 459         <term>User unit directories</term>
 460
 461         <listitem><para>Similar rules apply for the user unit
 462         directories. However, here the
 463         <ulink url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 464         Base Directory specification</ulink> is followed to find
 465         units. Applications should place their unit files in the
 466         directory returned by <command>pkg-config systemd
 467         --variable=systemduserunitdir</command>. Global configuration
 468         is done in the directory reported by <command>pkg-config
 469         systemd --variable=systemduserconfdir</command>. The
 470         <command>enable</command> and <command>disable</command>
 471         commands of the
 472         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
 473         tool can handle both global (i.e. for all users) and private
 474         (for one user) enabling/disabling of units. Full list of
 475         directories is provided in
 476         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
 477         </para></listitem>
 478       </varlistentry>
 479     </variablelist>
 480
 481     <variablelist>
 482       <varlistentry>
 483         <term>SysV init scripts directory</term>
 484
 485         <listitem><para>The location of the SysV init script directory
 486         varies between distributions. If systemd cannot find a native
 487         unit file for a requested service, it will look for a SysV
 488         init script of the same name (with the
 489         <filename>.service</filename> suffix
 490         removed).</para></listitem>
 491       </varlistentry>
 492     </variablelist>
 493
 494     <variablelist>
 495       <varlistentry>
 496         <term>SysV runlevel link farm directory</term>
 497
 498         <listitem><para>The location of the SysV runlevel link farm
 499         directory varies between distributions. systemd will take the
 500         link farm into account when figuring out whether a service
 501         shall be enabled. Note that a service unit with a native unit
 502         configuration file cannot be started by activating it in the
 503         SysV runlevel link farm.</para></listitem>
 504       </varlistentry>
 505     </variablelist>
 506   </refsect1>
 507
 508   <refsect1>
 509     <title>Signals</title>
 510
 511     <variablelist>
 512       <varlistentry>
 513         <term><constant>SIGTERM</constant></term>
 514
 515         <listitem><para>Upon receiving this signal the systemd system
 516         manager serializes its state, reexecutes itself and
 517         deserializes the saved state again. This is mostly equivalent
 518         to <command>systemctl daemon-reexec</command>.</para>
 519
 520         <para>systemd user managers will start the
 521         <filename>exit.target</filename> unit when this signal is
 522         received. This is mostly equivalent to <command>systemctl
 523         --user start exit.target</command>.</para></listitem>
 524       </varlistentry>
 525
 526       <varlistentry>
 527         <term><constant>SIGINT</constant></term>
 528
 529         <listitem><para>Upon receiving this signal the systemd system
 530         manager will start the
 531         <filename>ctrl-alt-del.target</filename> unit. This is mostly
 532         equivalent to <command>systemctl start
 533         ctl-alt-del.target</command>. If this signal is received more
 534         often than 7 times per 2s an immediate reboot is triggered.
 535         Note that pressing Ctrl-Alt-Del on the console will trigger
 536         this signal. Hence, if a reboot is hanging pressing
 537         Ctrl-Alt-Del more than 7 times in 2s is a relatively safe way
 538         to trigger an immediate reboot.</para>
 539
 540         <para>systemd user managers treat this signal the same way as
 541         <constant>SIGTERM</constant>.</para></listitem>
 542       </varlistentry>
 543
 544       <varlistentry>
 545         <term><constant>SIGWINCH</constant></term>
 546
 547         <listitem><para>When this signal is received the systemd
 548         system manager will start the
 549         <filename>kbrequest.target</filename> unit. This is mostly
 550         equivalent to <command>systemctl start
 551         kbrequest.target</command>.</para>
 552
 553         <para>This signal is ignored by systemd user
 554         managers.</para></listitem>
 555       </varlistentry>
 556
 557       <varlistentry>
 558         <term><constant>SIGPWR</constant></term>
 559
 560         <listitem><para>When this signal is received the systemd
 561         manager will start the <filename>sigpwr.target</filename>
 562         unit. This is mostly equivalent to <command>systemctl start
 563         sigpwr.target</command>.</para></listitem>
 564       </varlistentry>
 565
 566       <varlistentry>
 567         <term><constant>SIGUSR1</constant></term>
 568
 569         <listitem><para>When this signal is received the systemd
 570         manager will try to reconnect to the D-Bus
 571         bus.</para></listitem>
 572       </varlistentry>
 573
 574       <varlistentry>
 575         <term><constant>SIGUSR2</constant></term>
 576
 577         <listitem><para>When this signal is received the systemd
 578         manager will log its complete state in human readable form.
 579         The data logged is the same as printed by
 580         <command>systemd-analyze dump</command>.</para></listitem>
 581       </varlistentry>
 582
 583       <varlistentry>
 584         <term><constant>SIGHUP</constant></term>
 585
 586         <listitem><para>Reloads the complete daemon configuration.
 587         This is mostly equivalent to <command>systemctl
 588         daemon-reload</command>.</para></listitem>
 589       </varlistentry>
 590
 591       <varlistentry>
 592         <term><constant>SIGRTMIN+0</constant></term>
 593
 594         <listitem><para>Enters default mode, starts the
 595         <filename>default.target</filename> unit. This is mostly
 596         equivalent to <command>systemctl start
 597         default.target</command>.</para></listitem>
 598       </varlistentry>
 599
 600       <varlistentry>
 601         <term><constant>SIGRTMIN+1</constant></term>
 602
 603         <listitem><para>Enters rescue mode, starts the
 604         <filename>rescue.target</filename> unit. This is mostly
 605         equivalent to <command>systemctl isolate
 606         rescue.target</command>.</para></listitem>
 607       </varlistentry>
 608
 609       <varlistentry>
 610         <term><constant>SIGRTMIN+2</constant></term>
 611
 612         <listitem><para>Enters emergency mode, starts the
 613         <filename>emergency.service</filename> unit. This is mostly
 614         equivalent to <command>systemctl isolate
 615         emergency.service</command>.</para></listitem>
 616       </varlistentry>
 617
 618       <varlistentry>
 619         <term><constant>SIGRTMIN+3</constant></term>
 620
 621         <listitem><para>Halts the machine, starts the
 622         <filename>halt.target</filename> unit. This is mostly
 623         equivalent to <command>systemctl start
 624         halt.target</command>.</para></listitem>
 625       </varlistentry>
 626
 627       <varlistentry>
 628         <term><constant>SIGRTMIN+4</constant></term>
 629
 630         <listitem><para>Powers off the machine, starts the
 631         <filename>poweroff.target</filename> unit. This is mostly
 632         equivalent to <command>systemctl start
 633         poweroff.target</command>.</para></listitem>
 634       </varlistentry>
 635
 636       <varlistentry>
 637         <term><constant>SIGRTMIN+5</constant></term>
 638
 639         <listitem><para>Reboots the machine, starts the
 640         <filename>reboot.target</filename> unit. This is mostly
 641         equivalent to <command>systemctl start
 642         reboot.target</command>.</para></listitem>
 643       </varlistentry>
 644
 645       <varlistentry>
 646         <term><constant>SIGRTMIN+6</constant></term>
 647
 648         <listitem><para>Reboots the machine via kexec, starts the
 649         <filename>kexec.target</filename> unit. This is mostly
 650         equivalent to <command>systemctl start
 651         kexec.target</command>.</para></listitem>
 652       </varlistentry>
 653
 654       <varlistentry>
 655         <term><constant>SIGRTMIN+13</constant></term>
 656
 657         <listitem><para>Immediately halts the machine.</para></listitem>
 658       </varlistentry>
 659
 660       <varlistentry>
 661         <term><constant>SIGRTMIN+14</constant></term>
 662
 663         <listitem><para>Immediately powers off the machine.</para></listitem>
 664       </varlistentry>
 665
 666       <varlistentry>
 667         <term><constant>SIGRTMIN+15</constant></term>
 668
 669         <listitem><para>Immediately reboots the machine.</para></listitem>
 670       </varlistentry>
 671
 672       <varlistentry>
 673         <term><constant>SIGRTMIN+16</constant></term>
 674
 675         <listitem><para>Immediately reboots the machine with kexec.</para></listitem>
 676       </varlistentry>
 677
 678       <varlistentry>
 679         <term><constant>SIGRTMIN+20</constant></term>
 680
 681         <listitem><para>Enables display of status messages on the
 682         console, as controlled via
 683         <varname>systemd.show_status=1</varname> on the kernel command
 684         line.</para></listitem>
 685       </varlistentry>
 686
 687       <varlistentry>
 688         <term><constant>SIGRTMIN+21</constant></term>
 689
 690         <listitem><para>Disables display of
 691         status messages on the console, as
 692         controlled via
 693         <varname>systemd.show_status=0</varname>
 694         on the kernel command
 695         line.</para></listitem>
 696       </varlistentry>
 697
 698       <varlistentry>
 699         <term><constant>SIGRTMIN+22</constant></term>
 700         <term><constant>SIGRTMIN+23</constant></term>
 701
 702         <listitem><para>Sets the log level to <literal>debug</literal>
 703         (or <literal>info</literal> on
 704         <constant>SIGRTMIN+23</constant>), as controlled via
 705         <varname>systemd.log_level=debug</varname> (or
 706         <varname>systemd.log_level=info</varname> on
 707         <constant>SIGRTMIN+23</constant>) on the kernel command
 708         line.</para></listitem>
 709       </varlistentry>
 710
 711       <varlistentry>
 712         <term><constant>SIGRTMIN+24</constant></term>
 713
 714         <listitem><para>Immediately exits the manager (only available
 715         for --user instances).</para></listitem>
 716       </varlistentry>
 717
 718       <varlistentry>
 719         <term><constant>SIGRTMIN+26</constant></term>
 720         <term><constant>SIGRTMIN+27</constant></term>
 721         <term><constant>SIGRTMIN+28</constant></term>
 722
 723         <listitem><para>Sets the log level to
 724         <literal>journal-or-kmsg</literal> (or
 725         <literal>console</literal> on
 726         <constant>SIGRTMIN+27</constant>, <literal>kmsg</literal> on
 727         <constant>SIGRTMIN+28</constant>), as controlled via
 728         <varname>systemd.log_target=journal-or-kmsg</varname> (or
 729         <varname>systemd.log_target=console</varname> on
 730         <constant>SIGRTMIN+27</constant> or
 731         <varname>systemd.log_target=kmsg</varname> on
 732         <constant>SIGRTMIN+28</constant>) on the kernel command
 733         line.</para></listitem>
 734       </varlistentry>
 735     </variablelist>
 736   </refsect1>
 737
 738   <refsect1>
 739     <title>Environment</title>
 740
 741     <variablelist class='environment-variables'>
 742       <varlistentry>
 743         <term><varname>$SYSTEMD_LOG_LEVEL</varname></term>
 744         <listitem><para>systemd reads the log level from this
 745         environment variable. This can be overridden with
 746         <option>--log-level=</option>.</para></listitem>
 747       </varlistentry>
 748
 749       <varlistentry>
 750         <term><varname>$SYSTEMD_LOG_TARGET</varname></term>
 751         <listitem><para>systemd reads the log target from this
 752         environment variable. This can be overridden with
 753         <option>--log-target=</option>.</para></listitem>
 754       </varlistentry>
 755
 756       <varlistentry>
 757         <term><varname>$SYSTEMD_LOG_COLOR</varname></term>
 758         <listitem><para>Controls whether systemd highlights important
 759         log messages. This can be overridden with
 760         <option>--log-color=</option>.</para></listitem>
 761       </varlistentry>
 762
 763       <varlistentry>
 764         <term><varname>$SYSTEMD_LOG_LOCATION</varname></term>
 765         <listitem><para>Controls whether systemd prints the code
 766         location along with log messages. This can be overridden with
 767         <option>--log-location=</option>.</para></listitem>
 768       </varlistentry>
 769
 770       <varlistentry>
 771         <term><varname>$XDG_CONFIG_HOME</varname></term>
 772         <term><varname>$XDG_CONFIG_DIRS</varname></term>
 773         <term><varname>$XDG_DATA_HOME</varname></term>
 774         <term><varname>$XDG_DATA_DIRS</varname></term>
 775
 776         <listitem><para>The systemd user manager uses these variables
 777         in accordance to the <ulink
 778         url="http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html">XDG
 779         Base Directory specification</ulink> to find its
 780         configuration.</para></listitem>
 781       </varlistentry>
 782
 783       <varlistentry>
 784         <term><varname>$SYSTEMD_UNIT_PATH</varname></term>
 785
 786         <listitem><para>Controls where systemd looks for unit
 787         files.</para></listitem>
 788       </varlistentry>
 789
 790       <varlistentry>
 791         <term><varname>$SYSTEMD_SYSVINIT_PATH</varname></term>
 792
 793         <listitem><para>Controls where systemd looks for SysV init
 794         scripts.</para></listitem>
 795       </varlistentry>
 796
 797       <varlistentry>
 798         <term><varname>$SYSTEMD_SYSVRCND_PATH</varname></term>
 799
 800         <listitem><para>Controls where systemd looks for SysV init
 801         script runlevel link farms.</para></listitem>
 802       </varlistentry>
 803
 804       <varlistentry>
 805         <term><varname>$LISTEN_PID</varname></term>
 806         <term><varname>$LISTEN_FDS</varname></term>
 807
 808         <listitem><para>Set by systemd for supervised processes during
 809         socket-based activation. See
 810         <citerefentry><refentrytitle>sd_listen_fds</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 811         for more information. </para></listitem>
 812       </varlistentry>
 813
 814       <varlistentry>
 815         <term><varname>$NOTIFY_SOCKET</varname></term>
 816
 817         <listitem><para>Set by systemd for supervised processes for
 818         status and start-up completion notification. See
 819         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 820         for more information. </para></listitem>
 821       </varlistentry>
 822     </variablelist>
 823   </refsect1>
 824
 825   <refsect1>
 826     <title>Kernel Command Line</title>
 827
 828     <para>When run as system instance systemd parses a number of
 829     kernel command line arguments<footnote><para>If run inside a Linux
 830     container these arguments may be passed as command line arguments
 831     to systemd itself, next to any of the command line options listed
 832     in the Options section above. If run outside of Linux containers,
 833     these arguments are parsed from <filename>/proc/cmdline</filename>
 834     instead.</para></footnote>:</para>
 835
 836     <variablelist class='kernel-commandline-options'>
 837       <varlistentry>
 838         <term><varname>systemd.unit=</varname></term>
 839         <term><varname>rd.systemd.unit=</varname></term>
 840
 841         <listitem><para>Overrides the unit to activate on boot.
 842         Defaults to <filename>default.target</filename>. This may be
 843         used to temporarily boot into a different boot unit, for
 844         example <filename>rescue.target</filename> or
 845         <filename>emergency.service</filename>. See
 846         <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 847         for details about these units. The option prefixed with
 848         <literal>rd.</literal> is honored only in the initial RAM disk
 849         (initrd), while the one that is not prefixed only in the main
 850         system.</para></listitem>
 851       </varlistentry>
 852
 853       <varlistentry>
 854         <term><varname>systemd.dump_core=</varname></term>
 855
 856         <listitem><para>Takes a boolean argument. If
 857         <option>true</option>, systemd dumps core when it crashes.
 858         Otherwise, no core dump is created. Defaults to
 859         <option>true</option>.</para></listitem>
 860       </varlistentry>
 861
 862       <varlistentry>
 863         <term><varname>systemd.crash_shell=</varname></term>
 864
 865         <listitem><para>Takes a boolean argument. If
 866         <option>true</option>, systemd spawns a shell when it crashes.
 867         Otherwise, no shell is spawned. Defaults to
 868         <option>false</option>, for security reasons, as the shell is
 869         not protected by any password
 870         authentication.</para></listitem>
 871       </varlistentry>
 872
 873       <varlistentry>
 874         <term><varname>systemd.crash_chvt=</varname></term>
 875
 876         <listitem><para>Takes an integer argument. If positive systemd
 877         activates the specified virtual terminal when it crashes.
 878         Defaults to <constant>-1</constant>.</para></listitem>
 879       </varlistentry>
 880
 881       <varlistentry>
 882         <term><varname>systemd.confirm_spawn=</varname></term>
 883
 884         <listitem><para>Takes a boolean argument. If
 885         <option>true</option>, asks for confirmation when spawning
 886         processes. Defaults to
 887         <option>false</option>.</para></listitem>
 888       </varlistentry>
 889
 890       <varlistentry>
 891         <term><varname>systemd.show_status=</varname></term>
 892
 893         <listitem><para>Takes a boolean argument or the constant
 894         <constant>auto</constant>. If <option>true</option>, shows
 895         terse service status updates on the console during bootup.
 896         <constant>auto</constant> behaves like <option>false</option>
 897         until a service fails or there is a significant delay in boot.
 898         Defaults to <option>true</option>, unless
 899         <option>quiet</option> is passed as kernel command line option
 900         in which case it defaults to
 901         <constant>auto</constant>.</para></listitem>
 902       </varlistentry>
 903
 904       <varlistentry>
 905         <term><varname>systemd.log_target=</varname></term>
 906         <term><varname>systemd.log_level=</varname></term>
 907         <term><varname>systemd.log_color=</varname></term>
 908         <term><varname>systemd.log_location=</varname></term>
 909
 910         <listitem><para>Controls log output, with the same effect as
 911         the <varname>$SYSTEMD_LOG_TARGET</varname>,
 912         <varname>$SYSTEMD_LOG_LEVEL</varname>,
 913         <varname>$SYSTEMD_LOG_COLOR</varname>,
 914         <varname>$SYSTEMD_LOG_LOCATION</varname> environment variables
 915         described above.</para></listitem>
 916       </varlistentry>
 917
 918       <varlistentry>
 919         <term><varname>systemd.default_standard_output=</varname></term>
 920         <term><varname>systemd.default_standard_error=</varname></term>
 921         <listitem><para>Controls default standard output and error
 922         output for services, with the same effect as the
 923         <option>--default-standard-output=</option> and
 924         <option>--default-standard-error=</option> command line
 925         arguments described above, respectively.</para></listitem>
 926       </varlistentry>
 927
 928       <varlistentry>
 929         <term><varname>systemd.setenv=</varname></term>
 930
 931         <listitem><para>Takes a string argument in the form
 932         VARIABLE=VALUE. May be used to set default environment
 933         variables to add to forked child processes. May be used more
 934         than once to set multiple variables.</para></listitem>
 935       </varlistentry>
 936
 937       <varlistentry>
 938         <term><varname>quiet</varname></term>
 939
 940         <listitem><para>Turn off status output at boot, much like
 941         <varname>systemd.show_status=false</varname> would. Note that
 942         this option is also read by the kernel itself and disables
 943         kernel log output. Passing this option hence turns off the
 944         usual output from both the system manager and the kernel.
 945         </para></listitem>
 946       </varlistentry>
 947
 948       <varlistentry>
 949         <term><varname>debug</varname></term>
 950
 951         <listitem><para>Turn on debugging output. This is equivalent
 952         to <varname>systemd.log_level=debug</varname>. Note that this
 953         option is also read by the kernel itself and enables kernel
 954         debug output. Passing this option hence turns on the debug
 955         output from both the system manager and the
 956         kernel.</para></listitem>
 957       </varlistentry>
 958
 959       <varlistentry>
 960         <term><varname>emergency</varname></term>
 961         <term><varname>-b</varname></term>
 962
 963         <listitem><para>Boot into emergency mode. This is equivalent
 964         to <varname>systemd.unit=emergency.target</varname> and
 965         provided for compatibility reasons and to be easier to
 966         type.</para></listitem>
 967       </varlistentry>
 968
 969       <varlistentry>
 970         <term><varname>rescue</varname></term>
 971         <term><varname>single</varname></term>
 972         <term><varname>s</varname></term>
 973         <term><varname>S</varname></term>
 974         <term><varname>1</varname></term>
 975
 976         <listitem><para>Boot into rescue mode. This is equivalent to
 977         <varname>systemd.unit=rescue.target</varname> and provided for
 978         compatibility reasons and to be easier to
 979         type.</para></listitem>
 980       </varlistentry>
 981
 982       <varlistentry>
 983         <term><varname>2</varname></term>
 984         <term><varname>3</varname></term>
 985         <term><varname>4</varname></term>
 986         <term><varname>5</varname></term>
 987
 988         <listitem><para>Boot into the specified legacy SysV runlevel.
 989         These are equivalent to
 990         <varname>systemd.unit=runlevel2.target</varname>,
 991         <varname>systemd.unit=runlevel3.target</varname>,
 992         <varname>systemd.unit=runlevel4.target</varname>, and
 993         <varname>systemd.unit=runlevel5.target</varname>,
 994         respectively, and provided for compatibility reasons and to be
 995         easier to type.</para></listitem>
 996       </varlistentry>
 997
 998       <varlistentry>
 999         <term><varname>locale.LANG=</varname></term>
1000         <term><varname>locale.LANGUAGE=</varname></term>
1001         <term><varname>locale.LC_CTYPE=</varname></term>
1002         <term><varname>locale.LC_NUMERIC=</varname></term>
1003         <term><varname>locale.LC_TIME=</varname></term>
1004         <term><varname>locale.LC_COLLATE=</varname></term>
1005         <term><varname>locale.LC_MONETARY=</varname></term>
1006         <term><varname>locale.LC_MESSAGES=</varname></term>
1007         <term><varname>locale.LC_PAPER=</varname></term>
1008         <term><varname>locale.LC_NAME=</varname></term>
1009         <term><varname>locale.LC_ADDRESS=</varname></term>
1010         <term><varname>locale.LC_TELEPHONE=</varname></term>
1011         <term><varname>locale.LC_MEASUREMENT=</varname></term>
1012         <term><varname>locale.LC_IDENTIFICATION=</varname></term>
1013
1014         <listitem><para>Set the system locale to use. This overrides
1015         the settings in <filename>/etc/locale.conf</filename>. For
1016         more information see
1017         <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1018         and
1019         <citerefentry project='man-pages'><refentrytitle>locale</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
1020         </para></listitem>
1021       </varlistentry>
1022     </variablelist>
1023
1024     <para>For other kernel command line parameters understood by
1025     components of the core OS, please refer to
1026     <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>.</para>
1027   </refsect1>
1028
1029   <refsect1>
1030     <title>Sockets and FIFOs</title>
1031
1032     <variablelist>
1033       <varlistentry>
1034         <term><filename>/run/systemd/notify</filename></term>
1035
1036         <listitem><para>Daemon status notification socket. This is an
1037         <constant>AF_UNIX</constant> datagram socket and is used to
1038         implement the daemon notification logic as implemented by
1039         <citerefentry><refentrytitle>sd_notify</refentrytitle><manvolnum>3</manvolnum></citerefentry>.</para></listitem>
1040
1041       </varlistentry>
1042
1043       <varlistentry>
1044         <term><filename>/run/systemd/private</filename></term>
1045
1046         <listitem><para>Used internally as communication channel
1047         between
1048         <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
1049         and the systemd process. This is an
1050         <constant>AF_UNIX</constant> stream socket. This interface is
1051         private to systemd and should not be used in external
1052         projects.</para></listitem>
1053       </varlistentry>
1054
1055       <varlistentry>
1056         <term><filename>/dev/initctl</filename></term>
1057
1058         <listitem><para>Limited compatibility support for the SysV
1059         client interface, as implemented by the
1060         <filename>systemd-initctl.service</filename> unit. This is a
1061         named pipe in the file system. This interface is obsolete and
1062         should not be used in new applications.</para></listitem>
1063       </varlistentry>
1064     </variablelist>
1065   </refsect1>
1066
1067   <refsect1>
1068     <title>See Also</title>
1069     <para>
1070       The <ulink url="http://www.freedesktop.org/wiki/Software/systemd/">systemd Homepage</ulink>,
1071       <citerefentry><refentrytitle>systemd-system.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1072       <citerefentry project='man-pages'><refentrytitle>locale.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1073       <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1074       <citerefentry><refentrytitle>journalctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1075       <citerefentry><refentrytitle>systemd-notify</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1076       <citerefentry><refentrytitle>daemon</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1077       <citerefentry><refentrytitle>sd-daemon</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
1078       <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1079       <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1080       <citerefentry project='die-net'><refentrytitle>pkg-config</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1081       <citerefentry><refentrytitle>kernel-command-line</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1082       <citerefentry project='man-pages'><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1083       <citerefentry><refentrytitle>systemd.directives</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1084     </para>
1085   </refsect1>
1086
1087 </refentry>