+ <refsect1>
+ <title>Special System Units for Devices</title>
+
+ <para>Some target units are automatically pulled in as
+ devices of certain kinds show up in the system. These
+ may be used to automatically activate various services
+ based on the specific type of the available
+ hardware.</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><filename>bluetooth.target</filename></term>
+ <listitem>
+ <para>This target is started
+ automatically as soon as a
+ Bluetooth controller is
+ plugged in or becomes
+ available at boot.</para>
+
+ <para>This may be used to pull
+ in Bluetooth management
+ daemons dynamically when
+ Bluetooth hardware is
+ found.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>printer.target</filename></term>
+ <listitem>
+ <para>This target is started
+ automatically as soon as a
+ printer is plugged in or
+ becomes available at
+ boot.</para>
+
+ <para>This may be used to pull
+ in printer management
+ daemons dynamically when
+ printer hardware is
+ found.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>smartcard.target</filename></term>
+ <listitem>
+ <para>This target is started
+ automatically as soon as a
+ smartcard controller is
+ plugged in or becomes
+ available at boot.</para>
+
+ <para>This may be used to pull
+ in smartcard management
+ daemons dynamically when
+ smartcard hardware is
+ found.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>sound.target</filename></term>
+ <listitem>
+ <para>This target is started
+ automatically as soon as a
+ sound card is plugged in or
+ becomes available at
+ boot.</para>
+
+ <para>This may be used to pull
+ in audio management daemons
+ dynamically when audio
+ hardware is found.</para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+
+ <refsect1>
+ <title>Special Passive System Units </title>
+
+ <para>A number of special system targets are defined
+ that can be used to properly order boot-up of optional
+ services. These targets are generally not part of the
+ initial boot transaction, unless they are explicitly
+ pulled in by one of the implementing services. Note
+ specifically that these <emphasis>passive</emphasis>
+ target units are generally not pulled in by the
+ consumer of a service, but by the provider of the
+ service. This means: a consuming service should order
+ itself after these targets (as appropriate), but not
+ pull it in. A providing service should order itself
+ before these targets (as appropriate) and pull it in
+ (via a <varname>Wants=</varname> type
+ dependency).</para>
+
+ <para>Note that these passive units cannot be started
+ manually, i.e. <literal>systemctl start
+ time-sync.target</literal> will fail with an
+ error. They can only be pulled in by dependency. This
+ is enforced since they exist for ordering purposes
+ only and thus are not useful as only unit within a
+ transaction.</para>
+
+ <variablelist>
+ <varlistentry>
+ <term><filename>cryptsetup-pre.target</filename></term>
+ <listitem>
+ <para>This passive target unit
+ may be pulled in by services
+ that want to run before any
+ encrypted block device is set
+ up. All encrypted block
+ devices are set up after this
+ target has been reached. Since
+ the shutdown order is
+ implicitly the reverse
+ start-up order between units,
+ this target is particularly
+ useful to ensure that a
+ service is shut down only
+ after all encrypted block
+ devices are fully
+ stopped.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>local-fs-pre.target</filename></term>
+ <listitem>
+ <para>This target unit is
+ automatically ordered before
+ all local mount points marked
+ with <option>auto</option>
+ (see above). It can be used to
+ execute certain units before
+ all local mounts.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>network.target</filename></term>
+ <listitem>
+ <para>This unit is supposed to
+ indicate when network
+ functionality is available,
+ but it is only very weakly
+ defined what that is supposed
+ to mean, with one exception:
+ at shutdown, a unit that is
+ ordered after
+ <filename>network.target</filename>
+ will be stopped before the
+ network -- to whatever level
+ it might be set up then -- is
+ shut down. It is hence useful
+ when writing service files
+ that require network access on
+ shutdown, which should order
+ themselves after this target,
+ but not pull it in. Also see
+ <ulink
+ url="http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget">Running
+ Services After the Network is
+ up</ulink> for more
+ information. Also see
+ <filename>network-online.target</filename>
+ described above.</para>
+
+ <para>systemd automatically
+ adds dependencies of type
+ <varname>After=</varname> for
+ this target unit to all SysV
+ init script service units with
+ an LSB header referring to the
+ <literal>$network</literal>
+ facility.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>network-pre.target</filename></term>
+ <listitem>
+ <para>This passive target unit
+ may be pulled in by services
+ that want to run before any
+ network is set up, for example
+ for the purpose of setting up a
+ firewall. All network
+ management software orders
+ itself after this target, but
+ does not pull it in.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>nss-lookup.target</filename></term>
+ <listitem>
+ <para>A target that should be
+ used as synchronization point
+ for all host/network name
+ service lookups. Note that
+ this is independent of
+ user/group name lookups for
+ which
+ <filename>nss-user-lookup.target</filename>
+ should be used. All services
+ for which the availability of
+ full host/network name
+ resolution is essential should
+ be ordered after this target,
+ but not pull it in. systemd
+ automatically adds
+ dependencies of type
+ <varname>After=</varname> for
+ this target unit to all SysV
+ init script service units with
+ an LSB header referring to the
+ <literal>$named</literal>
+ facility.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>nss-user-lookup.target</filename></term>
+ <listitem>
+ <para>A target that should be
+ used as synchronization point
+ for all user/group name
+ service lookups. Note that
+ this is independent of
+ host/network name lookups for
+ which
+ <filename>nss-lookup.target</filename>
+ should be used. All services
+ for which the availability of
+ the full user/group database is
+ essential should be ordered
+ after this target, but not
+ pull it in. Note that system
+ users are always resolvable,
+ and hence do not require any
+ special ordering against this
+ target.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>remote-fs-pre.target</filename></term>
+ <listitem>
+ <para>This target unit is
+ automatically ordered before
+ all remote mount point units
+ (see above). It can be used to
+ run certain units before the
+ remote mounts are
+ established. Note that this
+ unit is generally not part of
+ the initial transaction,
+ unless the unit that wants to
+ be ordered before all remote
+ mounts pulls it in via a
+ <varname>Wants=</varname> type
+ dependency. If the unit wants
+ to be pulled in by the first
+ remote mount showing up, it
+ should use
+ <filename>network-online.target</filename>
+ (see above).</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>rpcbind.target</filename></term>
+ <listitem>
+ <para>The portmapper/rpcbind
+ pulls in this target and
+ orders itself before it, to
+ indicate its
+ availability. systemd
+ automatically adds
+ dependencies of type
+ <varname>After=</varname> for
+ this target unit to all SysV
+ init script service units with
+ an LSB header referring to the
+ <literal>$portmap</literal>
+ facility.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><filename>time-sync.target</filename></term>
+ <listitem>
+ <para>Services responsible for
+ synchronizing the system clock
+ from a remote source (such as
+ NTP client implementations)
+ should pull in this target and
+ order themselves before
+ it. All services where correct
+ time is essential should be
+ ordered after this unit, but
+ not pull it in. systemd
+ automatically adds
+ dependencies of type
+ <varname>After=</varname> for
+ this target unit to all SysV
+ init script service units with
+ an LSB header referring to the
+ <literal>$time</literal>
+ facility. </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ </refsect1>
+