man/systemd.special.xml

   1 <?xml version='1.0'?> <!--*-nxml-*-->
   2 <!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   3   "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
   4 <!-- SPDX-License-Identifier: LGPL-2.1+ -->
   5
   6 <refentry id="systemd.special">
   7
   8   <refentryinfo>
   9     <title>systemd.special</title>
  10     <productname>systemd</productname>
  11   </refentryinfo>
  12
  13   <refmeta>
  14     <refentrytitle>systemd.special</refentrytitle>
  15     <manvolnum>7</manvolnum>
  16   </refmeta>
  17
  18   <refnamediv>
  19     <refname>systemd.special</refname>
  20     <refpurpose>Special systemd units</refpurpose>
  21   </refnamediv>
  22
  23   <refsynopsisdiv><para>
  24     <!-- sort alphabetically, targets first --><filename>basic.target</filename>,
  25     <filename>bluetooth.target</filename>,
  26     <filename>cryptsetup-pre.target</filename>,
  27     <filename>cryptsetup.target</filename>,
  28     <filename>ctrl-alt-del.target</filename>,
  29     <filename>blockdev@.target</filename>,
  30     <filename>boot-complete.target</filename>,
  31     <filename>default.target</filename>,
  32     <filename>emergency.target</filename>,
  33     <filename>exit.target</filename>,
  34     <filename>final.target</filename>,
  35     <filename>first-boot-complete.target</filename>,
  36     <filename>getty.target</filename>,
  37     <filename>getty-pre.target</filename>,
  38     <filename>graphical.target</filename>,
  39     <filename>halt.target</filename>,
  40     <filename>hibernate.target</filename>,
  41     <filename>hybrid-sleep.target</filename>,
  42     <filename>suspend-then-hibernate.target</filename>,
  43     <filename>initrd.target</filename>,
  44     <filename>initrd-fs.target</filename>,
  45     <filename>initrd-root-device.target</filename>,
  46     <filename>initrd-root-fs.target</filename>,
  47     <filename>kbrequest.target</filename>,
  48     <filename>kexec.target</filename>,
  49     <filename>local-fs-pre.target</filename>,
  50     <filename>local-fs.target</filename>,
  51     <filename>machines.target</filename>
  52     <filename>multi-user.target</filename>,
  53     <filename>network-online.target</filename>,
  54     <filename>network-pre.target</filename>,
  55     <filename>network.target</filename>,
  56     <filename>nss-lookup.target</filename>,
  57     <filename>nss-user-lookup.target</filename>,
  58     <filename>paths.target</filename>,
  59     <filename>poweroff.target</filename>,
  60     <filename>printer.target</filename>,
  61     <filename>reboot.target</filename>,
  62     <filename>remote-cryptsetup.target</filename>,
  63     <filename>remote-fs-pre.target</filename>,
  64     <filename>remote-fs.target</filename>,
  65     <filename>rescue.target</filename>,
  66     <filename>rpcbind.target</filename>,
  67     <filename>runlevel2.target</filename>,
  68     <filename>runlevel3.target</filename>,
  69     <filename>runlevel4.target</filename>,
  70     <filename>runlevel5.target</filename>,
  71     <filename>shutdown.target</filename>,
  72     <filename>sigpwr.target</filename>,
  73     <filename>sleep.target</filename>,
  74     <filename>slices.target</filename>,
  75     <filename>smartcard.target</filename>,
  76     <filename>sockets.target</filename>,
  77     <filename>sound.target</filename>,
  78     <filename>suspend.target</filename>,
  79     <filename>swap.target</filename>,
  80     <filename>sysinit.target</filename>,
  81     <filename>system-update.target</filename>,
  82     <filename>system-update-pre.target</filename>,
  83     <filename>time-set.target</filename>,
  84     <filename>time-sync.target</filename>,
  85     <filename>timers.target</filename>,
  86     <filename>umount.target</filename>,
  87     <filename>usb-gadget.target</filename>,
  88     <!-- slices --><filename>-.slice</filename>,
  89     <filename>system.slice</filename>,
  90     <filename>user.slice</filename>,
  91     <filename>machine.slice</filename>,
  92     <!-- the rest --><filename>-.mount</filename>,
  93     <filename>dbus.service</filename>,
  94     <filename>dbus.socket</filename>,
  95     <filename>display-manager.service</filename>,
  96     <filename>init.scope</filename>,
  97     <filename>syslog.socket</filename>,
  98     <filename>system-update-cleanup.service</filename>
  99   </para></refsynopsisdiv>
 100
 101   <refsect1>
 102     <title>Description</title>
 103
 104     <para>A few units are treated specially by systemd. Many of them have
 105     special internal semantics and cannot be renamed, while others simply
 106     have a standard meaning and should be present on all systems.</para>
 107   </refsect1>
 108
 109   <refsect1>
 110     <title>Units managed by the system service manager</title>
 111
 112     <refsect2>
 113       <title>Special System Units</title>
 114
 115       <variablelist>
 116         <varlistentry>
 117           <term><filename>-.mount</filename></term>
 118           <listitem>
 119             <para>The root mount point, i.e. the mount unit for the <filename>/</filename>
 120             path. This unit is unconditionally active, during the entire time the system is up, as
 121             this mount point is where the basic userspace is running from.</para>
 122           </listitem>
 123         </varlistentry>
 124
 125         <varlistentry>
 126           <term><filename>basic.target</filename></term>
 127           <listitem>
 128             <para>A special target unit covering basic boot-up.</para>
 129
 130             <para>systemd automatically adds dependency of the type
 131             <varname>After=</varname> for this target unit to all
 132             services (except for those with
 133             <varname>DefaultDependencies=no</varname>).</para>
 134
 135             <para>Usually, this should pull-in all local mount points plus
 136             <filename>/var/</filename>, <filename>/tmp/</filename> and
 137             <filename>/var/tmp/</filename>, swap devices, sockets, timers,
 138             path units and other basic initialization necessary for general
 139             purpose daemons. The mentioned mount points are special cased
 140             to allow them to be remote.
 141             </para>
 142
 143             <para>This target usually does not pull in any non-target units
 144             directly, but rather does so indirectly via other early boot targets.
 145             It is instead meant as a synchronization point for late boot
 146             services. Refer to
 147             <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>
 148             for details on the targets involved.
 149             </para>
 150           </listitem>
 151         </varlistentry>
 152         <varlistentry>
 153           <term><filename>boot-complete.target</filename></term>
 154           <listitem>
 155             <para>This target is intended as generic synchronization point for services that shall determine or act on
 156             whether the boot process completed successfully. Order units that are required to succeed for a boot process
 157             to be considered successful before this unit, and add a <varname>Requires=</varname> dependency from the
 158             target unit to them. Order units that shall only run when the boot process is considered successful after the
 159             target unit and pull in the target from it, also with <varname>Requires=</varname>. Note that by default this
 160             target unit is not part of the initial boot transaction, but is supposed to be pulled in only if required by
 161             units that want to run only on successful boots.</para>
 162
 163             <para>See
 164             <citerefentry><refentrytitle>systemd-boot-check-no-failures.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
 165             for a service that implements a generic system health check and orders itself before
 166             <filename>boot-complete.target</filename>.</para>
 167
 168             <para>See
 169             <citerefentry><refentrytitle>systemd-bless-boot.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
 170             for a service that propagates boot success information to the boot loader, and orders itself after
 171             <filename>boot-complete.target</filename>.</para>
 172           </listitem>
 173         </varlistentry>
 174         <varlistentry>
 175           <term><filename>ctrl-alt-del.target</filename></term>
 176           <listitem>
 177             <para>systemd starts this target whenever Control+Alt+Del is
 178             pressed on the console. Usually, this should be aliased
 179             (symlinked) to <filename>reboot.target</filename>.</para>
 180           </listitem>
 181         </varlistentry>
 182         <varlistentry>
 183           <term><filename>cryptsetup.target</filename></term>
 184           <listitem>
 185             <para>A target that pulls in setup services for all
 186             encrypted block devices.</para>
 187           </listitem>
 188         </varlistentry>
 189         <varlistentry>
 190           <term><filename>dbus.service</filename></term>
 191           <listitem>
 192             <para>A special unit for the D-Bus bus daemon. As soon as
 193             this service is fully started up systemd will connect to it
 194             and register its service.</para>
 195           </listitem>
 196         </varlistentry>
 197         <varlistentry>
 198           <term><filename>dbus.socket</filename></term>
 199           <listitem>
 200             <para>A special unit for the D-Bus system bus socket. All
 201             units with <varname>Type=dbus</varname> automatically gain a
 202             dependency on this unit.</para>
 203           </listitem>
 204         </varlistentry>
 205         <varlistentry>
 206           <term><filename>default.target</filename></term>
 207           <listitem>
 208             <para>The default unit systemd starts at bootup. Usually, this should be aliased (symlinked) to
 209             <filename>multi-user.target</filename> or <filename>graphical.target</filename>. See
 210             <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
 211             more discussion.</para>
 212
 213             <para>The default unit systemd starts at bootup can be overridden with the
 214             <varname>systemd.unit=</varname> kernel command line option, or more conveniently, with the short
 215             names like <varname>single</varname>, <varname>rescue</varname>, <varname>1</varname>,
 216             <varname>3</varname>, <varname>5</varname>, …; see
 217             <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>.</para>
 218           </listitem>
 219         </varlistentry>
 220         <varlistentry>
 221           <term><filename>display-manager.service</filename></term>
 222           <listitem>
 223             <para>The display manager service. Usually, this should be
 224             aliased (symlinked) to <filename>gdm.service</filename> or a
 225             similar display manager service.</para>
 226           </listitem>
 227         </varlistentry>
 228         <varlistentry>
 229           <term><filename>emergency.target</filename></term>
 230           <listitem>
 231             <para>A special target unit that starts an emergency shell on the main console. This
 232             target does not pull in other services or mounts. It is the most minimal version of
 233             starting the system in order to acquire an interactive shell; the only processes running
 234             are usually just the system manager (PID 1) and the shell process. This unit may be used
 235             by specifying <varname>emergency</varname> on the kernel command line; it is
 236             also used when a file system check on a required file system fails and boot-up cannot
 237             continue. Compare with <filename>rescue.target</filename>, which serves a similar
 238             purpose, but also starts the most basic services and mounts all file systems.</para>
 239
 240             <para>In many ways booting into <filename>emergency.target</filename> is similar to the
 241             effect of booting with <literal>init=/bin/sh</literal> on the kernel command line,
 242             except that emergency mode provides you with the full system and service manager, and
 243             allows starting individual units in order to continue the boot process in steps.</para>
 244
 245             <para>Note that depending on how <filename>emergency.target</filename> is reached, the root file
 246             system might be mounted read-only or read-write (no remounting is done specially for this
 247             target). For example, the system may boot with root mounted read-only when <varname>ro</varname>
 248             is used on the kernel command line and remain this way for <filename>emergency.target</filename>,
 249             or the system may transition to <filename>emergency.target</filename> after the system has been
 250             partially booted and disks have already been remounted read-write.</para>
 251           </listitem>
 252         </varlistentry>
 253         <varlistentry>
 254           <term><filename>exit.target</filename></term>
 255           <listitem>
 256             <para>A special service unit for shutting down the system or
 257             user service manager. It is equivalent to
 258             <filename>poweroff.target</filename> on non-container
 259             systems, and also works in containers.</para>
 260
 261             <para>systemd will start this unit when it receives the
 262             <constant>SIGTERM</constant> or <constant>SIGINT</constant>
 263             signal when running as user service daemon.</para>
 264
 265             <para>Normally, this (indirectly) pulls in
 266             <filename>shutdown.target</filename>, which in turn should be
 267             conflicted by all units that want to be scheduled for
 268             shutdown when the service manager starts to exit.</para>
 269           </listitem>
 270         </varlistentry>
 271         <varlistentry>
 272           <term><filename>final.target</filename></term>
 273           <listitem>
 274             <para>A special target unit that is used during the shutdown
 275             logic and may be used to pull in late services after all
 276             normal services are already terminated and all mounts
 277             unmounted.
 278             </para>
 279           </listitem>
 280         </varlistentry>
 281         <varlistentry>
 282           <term><filename>getty.target</filename></term>
 283           <listitem>
 284             <para>A special target unit that pulls in statically
 285             configured local TTY <filename>getty</filename> instances.
 286             </para>
 287           </listitem>
 288         </varlistentry>
 289         <varlistentry>
 290           <term><filename>graphical.target</filename></term>
 291           <listitem>
 292             <para>A special target unit for setting up a graphical login
 293             screen. This pulls in
 294             <filename>multi-user.target</filename>.</para>
 295
 296             <para>Units that are needed for graphical logins shall add
 297             <varname>Wants=</varname> dependencies for their unit to
 298             this unit (or <filename>multi-user.target</filename>) during
 299             installation. This is best configured via
 300             <varname>WantedBy=graphical.target</varname> in the unit's
 301             [Install] section.</para>
 302           </listitem>
 303         </varlistentry>
 304         <varlistentry>
 305           <term><filename>hibernate.target</filename></term>
 306           <listitem>
 307             <para>A special target unit for hibernating the system. This
 308             pulls in <filename>sleep.target</filename>.</para>
 309           </listitem>
 310         </varlistentry>
 311         <varlistentry>
 312           <term><filename>hybrid-sleep.target</filename></term>
 313           <listitem>
 314             <para>A special target unit for hibernating and suspending
 315             the system at the same time. This pulls in
 316             <filename>sleep.target</filename>.</para>
 317           </listitem>
 318         </varlistentry>
 319         <varlistentry>
 320           <term><filename>suspend-then-hibernate.target</filename></term>
 321           <listitem>
 322             <para>A special target unit for suspending the system for a period
 323             of time, waking it and putting it into hibernate. This pulls in
 324             <filename>sleep.target</filename>.</para>
 325           </listitem>
 326         </varlistentry>
 327
 328         <varlistentry>
 329           <term><filename>halt.target</filename></term>
 330           <listitem>
 331             <para>A special target unit for shutting down and halting
 332             the system. Note that this target is distinct from
 333             <filename>poweroff.target</filename> in that it generally
 334             really just halts the system rather than powering it
 335             down.</para>
 336
 337             <para>Applications wanting to halt the system should not start this unit
 338             directly, but should instead execute <command>systemctl halt</command>
 339             (possibly with the <option>--no-block</option> option) or call
 340             <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
 341             <command>org.freedesktop.systemd1.Manager.Halt</command> D-Bus method
 342             directly.</para>
 343           </listitem>
 344         </varlistentry>
 345         <varlistentry>
 346           <term><filename>init.scope</filename></term>
 347           <listitem>
 348             <para>This scope unit is where the system and service manager (PID 1) itself resides. It
 349             is active as long as the system is running.</para>
 350           </listitem>
 351         </varlistentry>
 352         <varlistentry>
 353           <term><filename>initrd.target</filename></term>
 354           <listitem>
 355             <para>This is the default target in the initramfs, similar to <filename>default.target</filename>
 356             in the main system. It is used to mount the real root and transition to it. See
 357             <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
 358             more discussion.</para>
 359           </listitem>
 360         </varlistentry>
 361         <varlistentry>
 362           <term><filename>initrd-fs.target</filename></term>
 363           <listitem>
 364             <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 365             automatically adds dependencies of type
 366             <varname>Before=</varname> to
 367             <filename>sysroot-usr.mount</filename> and all mount points
 368             found in <filename>/etc/fstab</filename> that have
 369             <option>x-initrd.mount</option> and not have
 370             <option>noauto</option> mount options set.</para>
 371           </listitem>
 372         </varlistentry>
 373         <varlistentry>
 374           <term><filename>initrd-root-device.target</filename></term>
 375           <listitem>
 376             <para>A special initrd target unit that is reached when the root filesystem device is available, but before
 377             it has been mounted.
 378             <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 379             and
 380             <citerefentry><refentrytitle>systemd-gpt-auto-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 381             automatically setup the appropriate dependencies to make this happen.
 382             </para>
 383           </listitem>
 384         </varlistentry>
 385         <varlistentry>
 386           <term><filename>initrd-root-fs.target</filename></term>
 387           <listitem>
 388             <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 389             automatically adds dependencies of type
 390             <varname>Before=</varname> to the
 391             <filename>sysroot.mount</filename> unit, which is generated
 392             from the kernel command line.
 393             </para>
 394           </listitem>
 395         </varlistentry>
 396         <varlistentry>
 397           <term><filename>kbrequest.target</filename></term>
 398           <listitem>
 399             <para>systemd starts this target whenever Alt+ArrowUp is
 400             pressed on the console. Note that any user with physical access
 401             to the machine will be able to do this, without authentication,
 402             so this should be used carefully.</para>
 403           </listitem>
 404         </varlistentry>
 405         <varlistentry>
 406           <term><filename>kexec.target</filename></term>
 407           <listitem>
 408             <para>A special target unit for shutting down and rebooting
 409             the system via kexec.</para>
 410
 411             <para>Applications wanting to reboot the system should not start this unit
 412             directly, but should instead execute <command>systemctl kexec</command>
 413             (possibly with the <option>--no-block</option> option) or call
 414             <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
 415             <command>org.freedesktop.systemd1.Manager.KExec</command> D-Bus method
 416             directly.</para>
 417           </listitem>
 418         </varlistentry>
 419         <varlistentry>
 420           <term><filename>local-fs.target</filename></term>
 421           <listitem>
 422             <para><citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>3</manvolnum></citerefentry>
 423             automatically adds dependencies of type
 424             <varname>Before=</varname> to all mount units that refer to
 425             local mount points for this target unit. In addition, it
 426             adds dependencies of type <varname>Wants=</varname> to this
 427             target unit for those mounts listed in
 428             <filename>/etc/fstab</filename> that have the
 429             <option>auto</option> mount option set.</para>
 430           </listitem>
 431         </varlistentry>
 432         <varlistentry>
 433           <term><filename>machines.target</filename></term>
 434           <listitem>
 435             <para>A standard target unit for starting all the containers
 436             and other virtual machines. See <filename>systemd-nspawn@.service</filename>
 437             for an example.</para>
 438           </listitem>
 439         </varlistentry>
 440         <varlistentry>
 441           <term><filename>multi-user.target</filename></term>
 442           <listitem>
 443             <para>A special target unit for setting up a multi-user
 444             system (non-graphical). This is pulled in by
 445             <filename>graphical.target</filename>.</para>
 446
 447             <para>Units that are needed for a multi-user system shall
 448             add <varname>Wants=</varname> dependencies for their unit to
 449             this unit during installation. This is best configured via
 450             <varname>WantedBy=multi-user.target</varname> in the unit's
 451             [Install] section.</para>
 452           </listitem>
 453         </varlistentry>
 454         <varlistentry>
 455           <term><filename>network-online.target</filename></term>
 456           <listitem>
 457             <para>Units that strictly require a configured network
 458             connection should pull in
 459             <filename>network-online.target</filename> (via a
 460             <varname>Wants=</varname> type dependency) and order
 461             themselves after it. This target unit is intended to pull in
 462             a service that delays further execution until the network is
 463             sufficiently set up. What precisely this requires is left to
 464             the implementation of the network managing service.</para>
 465
 466             <para>Note the distinction between this unit and
 467             <filename>network.target</filename>. This unit is an active
 468             unit (i.e. pulled in by the consumer rather than the
 469             provider of this functionality) and pulls in a service which
 470             possibly adds substantial delays to further execution. In
 471             contrast, <filename>network.target</filename> is a passive
 472             unit (i.e. pulled in by the provider of the functionality,
 473             rather than the consumer) that usually does not delay
 474             execution much. Usually, <filename>network.target</filename>
 475             is part of the boot of most systems, while
 476             <filename>network-online.target</filename> is not, except
 477             when at least one unit requires it. Also see <ulink
 478             url="https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget">Running
 479             Services After the Network is up</ulink> for more
 480             information.</para>
 481
 482             <para>All mount units for remote network file systems
 483             automatically pull in this unit, and order themselves after
 484             it. Note that networking daemons that simply provide
 485             functionality to other hosts generally do not need to pull
 486             this in.</para>
 487
 488             <para>systemd automatically adds dependencies of type <varname>Wants=</varname> and
 489             <varname>After=</varname> for this target unit to all SysV init script service units
 490             with an LSB header referring to the <literal>$network</literal> facility.</para>
 491
 492             <para>Note that this unit is only useful during the original system start-up
 493             logic. After the system has completed booting up, it will not track the online state of
 494             the system anymore. Due to this it cannot be used as a network connection monitor
 495             concept, it is purely a one-time system start-up concept.</para>
 496             </listitem>
 497         </varlistentry>
 498         <varlistentry>
 499           <term><filename>paths.target</filename></term>
 500           <listitem>
 501             <para>A special target unit that sets up all path units (see
 502             <citerefentry><refentrytitle>systemd.path</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 503             for details) that shall be active after boot.</para>
 504
 505             <para>It is recommended that path units installed by
 506             applications get pulled in via <varname>Wants=</varname>
 507             dependencies from this unit. This is best configured via a
 508             <varname>WantedBy=paths.target</varname> in the path unit's
 509             [Install] section.</para>
 510           </listitem>
 511         </varlistentry>
 512         <varlistentry>
 513           <term><filename>poweroff.target</filename></term>
 514           <listitem>
 515             <para>A special target unit for shutting down and powering
 516             off the system.</para>
 517
 518             <para>Applications wanting to power off the system should not start this unit
 519             directly, but should instead execute <command>systemctl poweroff</command>
 520             (possibly with the <option>--no-block</option> option) or call
 521             <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
 522             <command>org.freedesktop.login1.Manager.PowerOff</command> D-Bus method
 523             directly.</para>
 524
 525             <para><filename>runlevel0.target</filename> is an alias for
 526             this target unit, for compatibility with SysV.</para>
 527           </listitem>
 528         </varlistentry>
 529         <varlistentry>
 530           <term><filename>reboot.target</filename></term>
 531           <listitem>
 532             <para>A special target unit for shutting down and rebooting
 533             the system.</para>
 534
 535             <para>Applications wanting to reboot the system should not start this unit
 536             directly, but should instead execute <command>systemctl reboot</command>
 537             (possibly with the <option>--no-block</option> option) or call
 538             <citerefentry><refentrytitle>systemd-logind</refentrytitle><manvolnum>8</manvolnum></citerefentry>'s
 539             <command>org.freedesktop.login1.Manager.Reboot</command> D-Bus method
 540             directly.</para>
 541
 542             <para><filename>runlevel6.target</filename> is an alias for
 543             this target unit, for compatibility with SysV.</para>
 544           </listitem>
 545         </varlistentry>
 546         <varlistentry>
 547           <term><filename>remote-cryptsetup.target</filename></term>
 548           <listitem>
 549             <para>Similar to <filename>cryptsetup.target</filename>, but for encrypted
 550             devices which are accessed over the network. It is used for
 551             <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>8</manvolnum></citerefentry>
 552             entries marked with <option>_netdev</option>.</para>
 553           </listitem>
 554         </varlistentry>
 555         <varlistentry>
 556           <term><filename>remote-fs.target</filename></term>
 557           <listitem>
 558             <para>Similar to <filename>local-fs.target</filename>, but
 559             for remote mount points.</para>
 560
 561             <para>systemd automatically adds dependencies of type
 562             <varname>After=</varname> for this target unit to all SysV
 563             init script service units with an LSB header referring to
 564             the <literal>$remote_fs</literal> facility.</para>
 565           </listitem>
 566         </varlistentry>
 567         <varlistentry>
 568           <term><filename>rescue.target</filename></term>
 569           <listitem>
 570             <para>A special target unit that pulls in the base system (including system mounts) and
 571             spawns a rescue shell. Isolate to this target in order to administer the system in
 572             single-user mode with all file systems mounted but with no services running, except for
 573             the most basic. Compare with <filename>emergency.target</filename>, which is much more
 574             reduced and does not provide the file systems or most basic services. Compare with
 575             <filename>multi-user.target</filename>, this target could be seen as
 576             <filename>single-user.target</filename>.</para>
 577
 578             <para><filename>runlevel1.target</filename> is an alias for this target unit, for
 579             compatibility with SysV.</para>
 580
 581             <para>Use the <literal>systemd.unit=rescue.target</literal> kernel command line option
 582             to boot into this mode. A short alias for this kernel command line option is
 583             <literal>1</literal>, for compatibility with SysV.</para>
 584           </listitem>
 585         </varlistentry>
 586         <varlistentry>
 587           <term><filename>runlevel2.target</filename></term>
 588           <term><filename>runlevel3.target</filename></term>
 589           <term><filename>runlevel4.target</filename></term>
 590           <term><filename>runlevel5.target</filename></term>
 591           <listitem>
 592             <para>These are targets that are called whenever the SysV
 593             compatibility code asks for runlevel 2, 3, 4, 5,
 594             respectively. It is a good idea to make this an alias for
 595             (i.e. symlink to) <filename>graphical.target</filename>
 596             (for runlevel 5) or <filename>multi-user.target</filename>
 597             (the others).</para>
 598           </listitem>
 599         </varlistentry>
 600         <varlistentry>
 601           <term><filename>shutdown.target</filename></term>
 602           <listitem>
 603             <para>A special target unit that terminates the services on
 604             system shutdown.</para>
 605
 606             <para>Services that shall be terminated on system shutdown
 607             shall add <varname>Conflicts=</varname> and
 608             <varname>Before=</varname> dependencies to this unit for
 609             their service unit, which is implicitly done when
 610             <varname>DefaultDependencies=yes</varname> is set (the
 611             default).</para>
 612           </listitem>
 613         </varlistentry>
 614         <varlistentry>
 615           <term><filename>sigpwr.target</filename></term>
 616           <listitem>
 617             <para>A special target that is started when systemd receives
 618             the SIGPWR process signal, which is normally sent by the
 619             kernel or UPS daemons when power fails.</para>
 620           </listitem>
 621         </varlistentry>
 622         <varlistentry>
 623           <term><filename>sleep.target</filename></term>
 624           <listitem>
 625             <para>A special target unit that is pulled in by
 626             <filename>suspend.target</filename>,
 627             <filename>hibernate.target</filename> and
 628             <filename>hybrid-sleep.target</filename> and may be used to
 629             hook units into the sleep state logic.</para>
 630           </listitem>
 631         </varlistentry>
 632         <varlistentry>
 633           <term><filename>slices.target</filename></term>
 634           <listitem>
 635             <para>A special target unit that sets up all slice units (see
 636             <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 637             for details) that shall always be active after boot. By default the generic
 638             <filename>system.slice</filename> slice unit as well as the root slice unit
 639             <filename>-.slice</filename> are pulled in and ordered before this unit (see
 640             below).</para>
 641
 642             <para>Adding slice units to <filename>slices.target</filename> is generally not
 643             necessary. Instead, when some unit that uses <varname>Slice=</varname> is started, the
 644             specified slice will be started automatically. Adding
 645             <varname>WantedBy=slices.target</varname> lines to the [Install]
 646             section should only be done for units that need to be always active. In that case care
 647             needs to be taken to avoid creating a loop through the automatic dependencies on
 648             "parent" slices.</para>
 649           </listitem>
 650         </varlistentry>
 651         <varlistentry>
 652           <term><filename>sockets.target</filename></term>
 653           <listitem>
 654             <para>A special target unit that sets up all socket
 655             units (see
 656             <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 657             for details) that shall be active after boot.</para>
 658
 659             <para>Services that can be socket-activated shall add
 660             <varname>Wants=</varname> dependencies to this unit for
 661             their socket unit during installation. This is best
 662             configured via a <varname>WantedBy=sockets.target</varname>
 663             in the socket unit's [Install]
 664             section.</para>
 665           </listitem>
 666         </varlistentry>
 667         <varlistentry>
 668           <term><filename>suspend.target</filename></term>
 669           <listitem>
 670             <para>A special target unit for suspending the system. This
 671             pulls in <filename>sleep.target</filename>.</para>
 672           </listitem>
 673         </varlistentry>
 674         <varlistentry>
 675           <term><filename>swap.target</filename></term>
 676           <listitem>
 677             <para>Similar to <filename>local-fs.target</filename>, but
 678             for swap partitions and swap files.</para>
 679           </listitem>
 680         </varlistentry>
 681         <varlistentry>
 682           <term><filename>sysinit.target</filename></term>
 683           <listitem>
 684             <para>systemd automatically adds dependencies of the types
 685             <varname>Requires=</varname> and <varname>After=</varname>
 686             for this target unit to all services (except for those with
 687             <varname>DefaultDependencies=no</varname>).</para>
 688
 689             <para>This target pulls in the services required for system
 690             initialization. System services pulled in by this target should
 691             declare <varname>DefaultDependencies=no</varname> and specify
 692             all their dependencies manually, including access to anything
 693             more than a read only root filesystem. For details on the
 694             dependencies of this target, refer to
 695             <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
 696             </para>
 697           </listitem>
 698         </varlistentry>
 699         <varlistentry>
 700           <term><filename>syslog.socket</filename></term>
 701           <listitem>
 702             <para>The socket unit syslog implementations should listen
 703             on. All userspace log messages will be made available on
 704             this socket. For more information about syslog integration,
 705             please consult the <ulink
 706             url="https://www.freedesktop.org/wiki/Software/systemd/syslog">Syslog
 707             Interface</ulink> document.</para>
 708           </listitem>
 709         </varlistentry>
 710         <varlistentry>
 711           <term><filename>system-update.target</filename></term>
 712           <term><filename>system-update-pre.target</filename></term>
 713           <term><filename>system-update-cleanup.service</filename></term>
 714           <listitem>
 715             <para>A special target unit that is used for offline system updates.
 716             <citerefentry><refentrytitle>systemd-system-update-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
 717             will redirect the boot process to this target if <filename>/system-update</filename>
 718             exists. For more information see
 719             <citerefentry><refentrytitle>systemd.offline-updates</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
 720             </para>
 721
 722             <para>Updates should happen before the <filename>system-update.target</filename> is
 723             reached, and the services which implement them should cause the machine to reboot. The
 724             main units executing the update should order themselves after
 725             <filename>system-update-pre.target</filename> but not pull it in. Services which want to
 726             run during system updates only, but before the actual system update is executed should
 727             order themselves before this unit and pull it in. As a safety measure, if this does not
 728             happen, and <filename>/system-update</filename> still exists after
 729             <filename>system-update.target</filename> is reached,
 730             <filename>system-update-cleanup.service</filename> will remove this symlink and reboot
 731             the machine.</para>
 732           </listitem>
 733         </varlistentry>
 734         <varlistentry>
 735           <term><filename>timers.target</filename></term>
 736           <listitem>
 737             <para>A special target unit that sets up all timer units
 738             (see
 739             <citerefentry><refentrytitle>systemd.timer</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 740             for details) that shall be active after boot.</para>
 741
 742             <para>It is recommended that timer units installed by
 743             applications get pulled in via <varname>Wants=</varname>
 744             dependencies from this unit. This is best configured via
 745             <varname>WantedBy=timers.target</varname> in the timer
 746             unit's [Install] section.</para>
 747           </listitem>
 748         </varlistentry>
 749         <varlistentry>
 750           <term><filename>umount.target</filename></term>
 751           <listitem>
 752             <para>A special target unit that unmounts all mount and
 753             automount points on system shutdown.</para>
 754
 755             <para>Mounts that shall be unmounted on system shutdown
 756             shall add Conflicts dependencies to this unit for their
 757             mount unit, which is implicitly done when
 758             <varname>DefaultDependencies=yes</varname> is set (the
 759             default).</para>
 760           </listitem>
 761         </varlistentry>
 762
 763       </variablelist>
 764     </refsect2>
 765
 766     <refsect2>
 767       <title>Special System Units for Devices</title>
 768
 769       <para>Some target units are automatically pulled in as devices of
 770       certain kinds show up in the system. These may be used to
 771       automatically activate various services based on the specific type
 772       of the available hardware.</para>
 773
 774       <variablelist>
 775         <varlistentry>
 776           <term><filename>bluetooth.target</filename></term>
 777           <listitem>
 778             <para>This target is started automatically as soon as a
 779             Bluetooth controller is plugged in or becomes available at
 780             boot.</para>
 781
 782             <para>This may be used to pull in Bluetooth management
 783             daemons dynamically when Bluetooth hardware is found.</para>
 784           </listitem>
 785         </varlistentry>
 786         <varlistentry>
 787           <term><filename>printer.target</filename></term>
 788           <listitem>
 789             <para>This target is started automatically as soon as a
 790             printer is plugged in or becomes available at boot.</para>
 791
 792             <para>This may be used to pull in printer management daemons
 793             dynamically when printer hardware is found.</para>
 794           </listitem>
 795         </varlistentry>
 796         <varlistentry>
 797           <term><filename>smartcard.target</filename></term>
 798           <listitem>
 799             <para>This target is started automatically as soon as a
 800             smartcard controller is plugged in or becomes available at
 801             boot.</para>
 802
 803             <para>This may be used to pull in smartcard management
 804             daemons dynamically when smartcard hardware is found.</para>
 805           </listitem>
 806         </varlistentry>
 807         <varlistentry>
 808           <term><filename>sound.target</filename></term>
 809           <listitem>
 810             <para>This target is started automatically as soon as a
 811             sound card is plugged in or becomes available at
 812             boot.</para>
 813
 814             <para>This may be used to pull in audio management daemons
 815             dynamically when audio hardware is found.</para>
 816           </listitem>
 817         </varlistentry>
 818         <varlistentry>
 819           <term><filename>usb-gadget.target</filename></term>
 820           <listitem>
 821             <para>This target is started automatically as soon as a
 822             USB Device Controller becomes available at boot.</para>
 823
 824             <para>This may be used to pull in usb gadget
 825             dynamically when UDC hardware is found.</para>
 826           </listitem>
 827         </varlistentry>
 828       </variablelist>
 829     </refsect2>
 830
 831     <refsect2>
 832       <title>Special Passive System Units </title>
 833
 834       <para>A number of special system targets are defined that can be
 835       used to properly order boot-up of optional services. These targets
 836       are generally not part of the initial boot transaction, unless
 837       they are explicitly pulled in by one of the implementing services.
 838       Note specifically that these <emphasis>passive</emphasis> target
 839       units are generally not pulled in by the consumer of a service,
 840       but by the provider of the service. This means: a consuming
 841       service should order itself after these targets (as appropriate),
 842       but not pull it in. A providing service should order itself before
 843       these targets (as appropriate) and pull it in (via a
 844       <varname>Wants=</varname> type dependency).</para>
 845
 846       <para>Note that these passive units cannot be started manually,
 847       i.e. <literal>systemctl start time-sync.target</literal> will fail
 848       with an error. They can only be pulled in by dependency. This is
 849       enforced since they exist for ordering purposes only and thus are
 850       not useful as only unit within a transaction.</para>
 851
 852       <variablelist>
 853         <varlistentry>
 854           <term><filename>blockdev@.target</filename></term>
 855           <listitem><para>This template unit is used to order mount units and other consumers of block
 856           devices after services that synthesize these block devices. In particular, this is intended to be
 857           used with storage services (such as
 858           <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>)
 859           that allocate and manage a virtual block device. Storage services are ordered before an instance of
 860           <filename>blockdev@.target</filename>, and the consumer units after it. The ordering is
 861           particularly relevant during shutdown, as it ensures that the mount is deactivated first and the
 862           service backing the mount later. The <filename>blockdev@.target</filename> instance should be
 863           pulled in via a <option>Wants=</option> dependency of the storage daemon and thus generally not be
 864           part of any transaction unless a storage daemon is used. The instance name for instances of this
 865           template unit must be a properly escaped block device node path, e.g.
 866           <filename index="false">blockdev@dev-mapper-foobar.target</filename> for the storage device
 867           <filename index="false">/dev/mapper/foobar</filename>.</para></listitem>
 868         </varlistentry>
 869         <varlistentry>
 870           <term><filename>cryptsetup-pre.target</filename></term>
 871           <listitem>
 872             <para>This passive target unit may be pulled in by services
 873             that want to run before any encrypted block device is set
 874             up. All encrypted block devices are set up after this target
 875             has been reached. Since the shutdown order is implicitly the
 876             reverse start-up order between units, this target is
 877             particularly useful to ensure that a service is shut down
 878             only after all encrypted block devices are fully
 879             stopped.</para>
 880           </listitem>
 881         </varlistentry>
 882         <varlistentry>
 883           <term><filename>first-boot-complete.target</filename></term>
 884           <listitem>
 885             <para>This passive target is intended as a synchronization point for units that need to run once
 886             during the first boot.  Only after all units ordered before this target have finished, will the
 887             <citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>
 888             be committed to disk, marking the first boot as completed.  If the boot is aborted at any time
 889             before that, the next boot will re-run any units with <varname>ConditionFirstBoot=yes</varname>.
 890             </para>
 891           </listitem>
 892         </varlistentry>
 893         <varlistentry>
 894           <term><filename>getty-pre.target</filename></term>
 895           <listitem>
 896             <para>A special passive target unit. Users of this target
 897             are expected to pull it in the boot transaction via
 898             a dependency (e.g. <varname>Wants=</varname>). Order your
 899             unit before this unit if you want to make use of the console
 900             just before <filename>getty</filename> is started.
 901             </para>
 902           </listitem>
 903         </varlistentry>
 904         <varlistentry>
 905           <term><filename>local-fs-pre.target</filename></term>
 906           <listitem>
 907             <para>This target unit is
 908             automatically ordered before
 909             all local mount points marked
 910             with <option>auto</option>
 911             (see above). It can be used to
 912             execute certain units before
 913             all local mounts.</para>
 914           </listitem>
 915         </varlistentry>
 916         <varlistentry>
 917           <term><filename>network.target</filename></term>
 918           <listitem>
 919             <para>This unit is supposed to indicate when network
 920             functionality is available, but it is only very weakly
 921             defined what that is supposed to mean, with one exception:
 922             at shutdown, a unit that is ordered after
 923             <filename>network.target</filename> will be stopped before
 924             the network — to whatever level it might be set up then —
 925             is shut down. It is hence useful when writing service files
 926             that require network access on shutdown, which should order
 927             themselves after this target, but not pull it in. Also see
 928             <ulink url="https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget">Running
 929             Services After the Network is up</ulink> for more
 930             information. Also see
 931             <filename>network-online.target</filename> described
 932             above.</para>
 933           </listitem>
 934         </varlistentry>
 935         <varlistentry>
 936           <term><filename>network-pre.target</filename></term>
 937           <listitem>
 938             <para>This passive target unit may be pulled in by services
 939             that want to run before any network is set up, for example
 940             for the purpose of setting up a firewall. All network
 941             management software orders itself after this target, but
 942             does not pull it in.</para>
 943           </listitem>
 944         </varlistentry>
 945         <varlistentry>
 946           <term><filename>nss-lookup.target</filename></term>
 947           <listitem>
 948             <para>A target that should be used as synchronization point for all host/network name
 949             service lookups. Note that this is independent of UNIX user/group name lookups for which
 950             <filename>nss-user-lookup.target</filename> should be used.  All services for which the
 951             availability of full host/network name resolution is essential should be ordered after
 952             this target, but not pull it in. systemd automatically adds dependencies of type
 953             <varname>After=</varname> for this target unit to all SysV init script service units
 954             with an LSB header referring to the <literal>$named</literal> facility.</para>
 955           </listitem>
 956         </varlistentry>
 957         <varlistentry>
 958           <term><filename>nss-user-lookup.target</filename></term>
 959           <listitem>
 960             <para>A target that should be used as synchronization point for all regular UNIX
 961             user/group name service lookups. Note that this is independent of host/network name
 962             lookups for which <filename>nss-lookup.target</filename> should be used. All services
 963             for which the availability of the full user/group database is essential should be
 964             ordered after this target, but not pull it in. All services which provide parts of the
 965             user/group database should be ordered before this target, and pull it in. Note that this
 966             unit is only relevant for regular users and groups — system users and groups are
 967             required to be resolvable during earliest boot already, and hence do not need any
 968             special ordering against this target.</para>
 969           </listitem>
 970         </varlistentry>
 971         <varlistentry>
 972           <term><filename>remote-fs-pre.target</filename></term>
 973           <listitem>
 974             <para>This target unit is automatically ordered before all
 975             mount point units (see above) and cryptsetup devices
 976             marked with the <option>_netdev</option>. It can be used to run
 977             certain units before remote encrypted devices and mounts are established.
 978             Note that this unit is generally not part of the initial
 979             transaction, unless the unit that wants to be ordered before
 980             all remote mounts pulls it in via a
 981             <varname>Wants=</varname> type dependency. If the unit wants
 982             to be pulled in by the first remote mount showing up, it
 983             should use <filename>network-online.target</filename> (see
 984             above).</para>
 985           </listitem>
 986         </varlistentry>
 987         <varlistentry>
 988           <term><filename>rpcbind.target</filename></term>
 989           <listitem>
 990             <para>The portmapper/rpcbind pulls in this target and orders
 991             itself before it, to indicate its availability. systemd
 992             automatically adds dependencies of type
 993             <varname>After=</varname> for this target unit to all SysV
 994             init script service units with an LSB header referring to
 995             the <literal>$portmap</literal> facility.</para>
 996           </listitem>
 997         </varlistentry>
 998         <varlistentry>
 999           <term><filename>time-set.target</filename></term>
1000           <listitem>
1001             <para>Services responsible for setting the system clock from
1002             a local source (such as a maintained timestamp file or
1003             imprecise real-time clock) should pull in this target and
1004             order themselves before it.  Services where approximate time
1005             is desired should be ordered after this unit, but not pull
1006             it in.  This target does not provide the accuracy guarantees
1007             of <filename>time-sync.target</filename>.</para>
1008           </listitem>
1009         </varlistentry>
1010         <varlistentry>
1011           <term><filename>time-sync.target</filename></term>
1012           <listitem>
1013             <para>Services responsible for synchronizing the system
1014             clock from a remote source (such as NTP client
1015             implementations) should pull in this target and order
1016             themselves before it. All services where correct time is
1017             essential should be ordered after this unit, but not pull it
1018             in. systemd automatically adds dependencies of type
1019             <varname>After=</varname> for this target unit to all SysV
1020             init script service units with an LSB header referring to
1021             the <literal>$time</literal> facility. </para>
1022           </listitem>
1023         </varlistentry>
1024       </variablelist>
1025     </refsect2>
1026
1027     <refsect2>
1028       <title>Special Slice Units</title>
1029
1030       <para>There are four <literal>.slice</literal> units which form the basis of the hierarchy for
1031       assignment of resources for services, users, and virtual machines or containers. See
1032       <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>7</manvolnum></citerefentry>
1033       for details about slice units.</para>
1034
1035       <variablelist>
1036         <varlistentry>
1037           <term><filename>-.slice</filename></term>
1038           <listitem>
1039             <para>The root slice is the root of the slice hierarchy. It usually does not contain
1040             units directly, but may be used to set defaults for the whole tree.</para>
1041           </listitem>
1042         </varlistentry>
1043
1044         <varlistentry>
1045           <term><filename>system.slice</filename></term>
1046           <listitem>
1047             <para>By default, all system services started by
1048             <command>systemd</command> are found in this slice.</para>
1049           </listitem>
1050         </varlistentry>
1051
1052         <varlistentry>
1053           <term><filename>user.slice</filename></term>
1054           <listitem>
1055             <para>By default, all user processes and services started on
1056             behalf of the user, including the per-user systemd instance
1057             are found in this slice.  This is pulled in by
1058             <filename>systemd-logind.service</filename>.</para>
1059           </listitem>
1060         </varlistentry>
1061
1062         <varlistentry>
1063           <term><filename>machine.slice</filename></term>
1064           <listitem>
1065             <para>By default, all virtual machines and containers
1066             registered with <command>systemd-machined</command> are
1067             found in this slice. This is pulled in by
1068             <filename>systemd-machined.service</filename>.</para>
1069           </listitem>
1070         </varlistentry>
1071       </variablelist>
1072     </refsect2>
1073   </refsect1>
1074
1075   <refsect1>
1076     <title>Units managed by the user service manager</title>
1077
1078     <refsect2>
1079       <title>Special User Units</title>
1080
1081       <para>When systemd runs as a user instance, the following special
1082       units are available:</para>
1083
1084       <variablelist>
1085         <varlistentry>
1086           <term><filename>default.target</filename></term>
1087           <listitem>
1088             <para>This is the main target of the user session, started by default. Various services that
1089             compose the normal user session should be pulled into this target. In this regard,
1090             <filename>default.target</filename> is similar to <filename>multi-user.target</filename> in the
1091             system instance, but it is a real unit, not an alias.</para>
1092           </listitem>
1093         </varlistentry>
1094       </variablelist>
1095
1096       <para>In addition, the following units are available which have definitions similar to their
1097       system counterparts:
1098       <filename>exit.target</filename>,
1099       <filename>shutdown.target</filename>,
1100       <filename>sockets.target</filename>,
1101       <filename>timers.target</filename>,
1102       <filename>paths.target</filename>,
1103       <filename>bluetooth.target</filename>,
1104       <filename>printer.target</filename>,
1105       <filename>smartcard.target</filename>,
1106       <filename>sound.target</filename>.</para>
1107     </refsect2>
1108
1109     <refsect2>
1110       <title>Special Passive User Units</title>
1111
1112       <variablelist>
1113         <varlistentry>
1114           <term><filename>graphical-session.target</filename></term>
1115           <listitem>
1116             <para>This target is active whenever any graphical session is running. It is used to
1117             stop user services which only apply to a graphical (X, Wayland, etc.) session when the
1118             session is terminated. Such services should have
1119             <literal>PartOf=graphical-session.target</literal> in their [Unit]
1120             section. A target for a particular session (e. g.
1121             <filename>gnome-session.target</filename>) starts and stops
1122             <literal>graphical-session.target</literal> with
1123             <literal>BindsTo=graphical-session.target</literal>.</para>
1124
1125             <para>Which services are started by a session target is determined by the
1126             <literal>Wants=</literal> and <literal>Requires=</literal> dependencies.  For services
1127             that can be enabled independently, symlinks in <literal>.wants/</literal> and
1128             <literal>.requires/</literal> should be used, see
1129             <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
1130             Those symlinks should either be shipped in packages, or should be added dynamically
1131             after installation, for example using <literal>systemctl add-wants</literal>, see
1132             <citerefentry><refentrytitle>systemctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
1133             </para>
1134
1135             <example>
1136               <title>Nautilus as part of a GNOME session</title>
1137
1138               <para><literal>gnome-session.target</literal> pulls in Nautilus as top-level service:</para>
1139
1140               <programlisting>[Unit]
1141   Description=User systemd services for GNOME graphical session
1142   Wants=nautilus.service
1143   BindsTo=graphical-session.target</programlisting>
1144
1145               <para><literal>nautilus.service</literal> gets stopped when the session stops:</para>
1146
1147               <programlisting>[Unit]
1148   Description=Render the desktop icons with Nautilus
1149   PartOf=graphical-session.target
1150
1151   [Service]
1152   …</programlisting>
1153             </example>
1154           </listitem>
1155         </varlistentry>
1156
1157         <varlistentry>
1158           <term><filename>graphical-session-pre.target</filename></term>
1159           <listitem>
1160             <para>This target contains services which set up the environment or global configuration
1161             of a graphical session, such as SSH/GPG agents (which need to export an environment
1162             variable into all desktop processes) or migration of obsolete d-conf keys after an OS
1163             upgrade (which needs to happen before starting any process that might use them). This
1164             target must be started before starting a graphical session like
1165             <filename>gnome-session.target</filename>.</para>
1166           </listitem>
1167         </varlistentry>
1168
1169         <varlistentry>
1170           <term><filename>xdg-desktop-autostart.target</filename></term>
1171           <listitem>
1172             <para>The XDG specification defines a way to autostart applications using XDG desktop files.
1173             systemd ships
1174             <citerefentry><refentrytitle>systemd-xdg-autostart-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
1175             for the XDG desktop files in autostart directories.
1176             Desktop Environments can opt-in to use this service by adding a <varname>Wants=</varname>
1177             dependency on <literal>xdg-desktop-autostart.target</literal>.</para>
1178           </listitem>
1179         </varlistentry>
1180       </variablelist>
1181     </refsect2>
1182   </refsect1>
1183
1184   <refsect1>
1185       <title>See Also</title>
1186       <para>
1187         <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
1188         <citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1189         <citerefentry><refentrytitle>systemd.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1190         <citerefentry><refentrytitle>systemd.socket</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1191         <citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1192         <citerefentry><refentrytitle>systemd.slice</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
1193         <citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
1194         <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
1195         <citerefentry><refentrytitle>user@.service</refentrytitle><manvolnum>5</manvolnum></citerefentry>
1196       </para>
1197   </refsect1>
1198
1199 </refentry>