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