man/systemd.xml

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