<
title>Description</
title>
<
para>A few units are treated specially by
systemd. They have special internal semantics and
cannot be renamed.</
para>
<
title>Special System Units</
title>
<
para>A special target unit
covering basic boot-up.</
para>
<
para>systemd automatically
adds dependencies of the types
<
varname>Requires=</
varname>
and <
varname>After=</
varname>
for this target unit to all
services (except for those
<
varname>DefaultDependencies=no</
varname>).</
para>
<
para>Usually this should
pull-in all mount points, swap
devices, sockets, timers, and
path units and other basic
initialization necessary for
<
para>systemd starts this
Control+Alt+Del is pressed on
the console. Usually this
should be aliased (symlinked)
<
para>A target that pulls in
<
para>A special unit for the
D-Bus bus daemon. As soon as
this service is fully started
up systemd will connect to it
<
para>A special unit for the
D-Bus system bus socket. All
<
varname>Type=dbus</
varname>
<
para>The default unit systemd
starts at bootup. Usually this
should be aliased (symlinked)
<
para>The default unit systemd
kernel command line option.</
para>
<
para>The display manager
service. Usually this should
be aliased (symlinked) to
or a similar display manager
<
para>A special target unit
console. This unit is supposed
to be used with the kernel
and has otherwise little use.
<
para>A special target unit
shutdown logic and may be used
to pull in late services after
already terminated and all
<
para>A special target unit
<
filename>getty</
filename>
<
para>A special target unit
for setting up a graphical
login screen. This pulls in
<
para>Units that are needed
for graphical logins shall add
<
varname>Wants=</
varname>
dependencies for their unit to
during installation. This is
<
literal>[Install]</
literal>
<
para>A special target unit
<
para>A special target unit
for hibernating and suspending the
system at the same time. This pulls in
<
para>A special target unit
for shutting down and halting
the system. Note that this
in that it generally really
just halts the system rather
than powering it down.</
para>
<
para>Applications wanting to
halt the system should start
<
para><
citerefentry><
refentrytitle>systemd-fstab-generator</
refentrytitle><
manvolnum>3</
manvolnum></
citerefentry>
<
varname>Before=</
varname> to
and all mount points found in
and not have <
option>noauto</
option>
mount options set.</
para>
<
para>systemd starts this
target whenever Alt+ArrowUp is
pressed on the console. This
is a good candidate to be
<
para>A special target unit
for shutting down and rebooting the system via kexec.</
para>
<
para>Applications wanting to
reboot the system with kexec should start
<
para><
citerefentry><
refentrytitle>systemd-fstab-generator</
refentrytitle><
manvolnum>3</
manvolnum></
citerefentry>
<
varname>Before=</
varname> to
all mount units that refer to
local mount points for this
target unit. In addition, it
adds dependencies of type
<
varname>Wants=</
varname> to
this target unit for those
<
option>auto</
option> mount
<
para>A special target unit
for setting up a multi-user
system (non-graphical). This
<
para>Units that are needed
for a multi-user system shall
add <
varname>Wants=</
varname>
dependencies for their unit to
installation. This is best
<
literal>[Install]</
literal>
<
para>Units that strictly
require a configured network
connection should pull in
<
varname>Wants=</
varname> type
themselves after it. This
target unit is intended to
pull in a service that delays
further execution until the
network is sufficiently set
implementation of the network
<
para>Note the distinction
functionality) and pulls in a
service which possibly adds
substantial delays to further
is a passive unit (
i.e. pulled
in by the provider of the
functionality, rather than the
consumer) that usually does
is part of the boot of most
is not, except when at least
one unit requires it. Also see
Services After the Network is
<
para>All mount units for
remote network file systems
automatically pull in this
unit, and order themselves
after it. Note that networking
daemons that simply provide
functionality to other hosts
generally do not need to pull
<
para>A special target unit
that sets up all path units
<
citerefentry><
refentrytitle>
systemd.path</
refentrytitle><
manvolnum>5</
manvolnum></
citerefentry>
for details) that shall be
active after boot.</
para>
<
para>It is recommended that
applications get pulled in via
<
varname>Wants=</
varname>
unit. This is best configured
<
literal>[Install]</
literal>
<
para>A special target unit
for shutting down and powering off the system.</
para>
<
para>Applications wanting to
power off the system should start
is an alias for this target
unit, for compatibility with SysV.</
para>
<
para>A special target unit
for shutting down and rebooting the system.</
para>
<
para>Applications wanting to
reboot the system should start
is an alias for this target
unit, for compatibility with SysV.</
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>$remote_fs</
literal>
<
para>A special target unit
for setting up the base system
and a rescue shell.</
para>
is an alias for this target
unit, for compatibility with SysV.</
para>
<
para><
citerefentry><
refentrytitle>systemd-fstab-generator</
refentrytitle><
manvolnum>3</
manvolnum></
citerefentry>
<
varname>Before=</
varname> to
unit, which is generated from
<
para>These are targets that
are called whenever the SysV
compatibility code asks for
respectively. It is a good
idea to make this an alias for
<
para>A special target unit
that terminates the services
on system shutdown.</
para>
<
para>Services that shall be
terminated on system shutdown
shall add <
varname>Conflicts=</
varname>
dependencies to this unit for
their service unit, which is
<
varname>DefaultDependencies=yes</
varname>
is set (the default).</
para>
<
para>A special target that is
started when systemd receives
the SIGPWR process signal,
which is normally sent by the
kernel or UPS daemons when
<
para>A special target unit
and may be used to hook units
<
para>A special target unit
<
citerefentry><
refentrytitle>
systemd.socket</
refentrytitle><
manvolnum>5</
manvolnum></
citerefentry>
for details) that shall be
active after boot.</
para>
<
para>Services that can be
socket-activated shall add
<
varname>Wants=</
varname>
dependencies to this unit for
installation. This is best
<
literal>[Install]</
literal>
<
para>A special target unit
<
para>A special target unit
covering early boot-up scripts.</
para>
syslog implementations should
listen on. All userspace log
available on this socket. For
more information about syslog
integration, please consult
<
para>A special target unit
that is used for off-line
<
citerefentry><
refentrytitle>systemd-system-update-generator</
refentrytitle><
manvolnum>8</
manvolnum></
citerefentry>
will redirect the boot process
<
filename>/system-update</
filename>
exists. For more information
Specification</
ulink>.</
para>
<
para>A special target unit
<
citerefentry><
refentrytitle>
systemd.timer</
refentrytitle><
manvolnum>5</
manvolnum></
citerefentry>
for details) that shall be
active after boot.</
para>
<
para>It is recommended that
applications get pulled in via
<
varname>Wants=</
varname>
unit. This is best configured
<
literal>[Install]</
literal>
<
para>A special target unit
that umounts all mount and
automount points on system
<
para>Mounts that shall be
unmounted on system shutdown
dependencies to this unit for
their mount unit, which is
<
varname>DefaultDependencies=yes</
varname>
is set (the default).</
para>
<
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
<
para>This target is started
automatically as soon as a
available at boot.</
para>
<
para>This may be used to pull
<
para>This target is started
automatically as soon as a
<
para>This may be used to pull
<
para>This target is started
automatically as soon as a
available at boot.</
para>
<
para>This may be used to pull
<
para>This target is started
automatically as soon as a
sound card is plugged in or
<
para>This may be used to pull
in audio management daemons
hardware is found.</
para>
<
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
<
para>Note that these passive units cannot be started
manually,
i.e. <
literal>systemctl start
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
<
para>This passive target unit
may be pulled in by services
that want to run before any
encrypted block device is set
devices are set up after this
target has been reached. Since
start-up order between units,
this target is particularly
service is shut down only
after all encrypted block
<
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
<
para>This unit is supposed to
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
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
Services After the Network is
<
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>
<
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
management software orders
itself after this target, but
does not pull it in.</
para>
<
para>A target that should be
used as synchronization point
service lookups. Note that
should be used. All services
for which the availability of
resolution is essential should
be ordered after this target,
but not pull it in. systemd
<
varname>After=</
varname> for
this target unit to all SysV
init script service units with
an LSB header referring to the
<
literal>$named</
literal>
<
para>A target that should be
used as synchronization point
service lookups. Note that
should be used. All services
for which the availability of
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
<
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
established. Note that this
unit is generally not part of
unless the unit that wants to
be ordered before all remote
<
varname>Wants=</
varname> type
dependency. If the unit wants
to be pulled in by the first
remote mount showing up, it
orders itself before it, to
<
varname>After=</
varname> for
this target unit to all SysV
init script service units with
an LSB header referring to the
<
literal>$portmap</
literal>
<
para>Services responsible for
synchronizing the system clock
from a remote source (such as
NTP client implementations)
should pull in this target and
it. All services where correct
time is essential should be
ordered after this unit, but
<
varname>After=</
varname> for
this target unit to all SysV
init script service units with
an LSB header referring to the
<
title>Special User Units</
title>
<
para>When systemd runs as a user instance, the
following special units are available, which have
similar definitions as their system counterparts:
<
para>In addition, the following special unit is
understood only when systemd runs as service instance:</
para>
<
para>A special service unit
user service manager.</
para>
<
para>Applications wanting to
terminate the user service
manager should start this
unit. If systemd receives
<
constant>SIGTERM</
constant> or <
constant>SIGINT</
constant> when running
as user service daemon, it will
<
para>Normally, this pulls in
conflicted by all units that
user service manager exit.</
para>
<
title>Special Slice Units</
title>
<
para>There are four <
literal>.slice</
literal> units
which form the basis of the hierarchy for assignment
of resources for services, users, and virtual machines
<
term><
filename>
-.slice</
filename></
term>
<
para>The root slice is the
root of the hierarchy. It
usually does not contain units
directly, but may be used to
set defaults for the whole
<
para>By default, all services
<
command>systemd</
command> are
found in this slice.</
para>
<
para>By default, all user
processes and services started
including the per-user systemd
instance are found in this
<
para>By default, all virtual
<
command>systemd-machined</
command>
<
citerefentry><
refentrytitle>systemd</
refentrytitle><
manvolnum>1</
manvolnum></
citerefentry>,
<
citerefentry><
refentrytitle>
systemd.unit</
refentrytitle><
manvolnum>5</
manvolnum></
citerefentry>,
<
citerefentry><
refentrytitle>
systemd.service</
refentrytitle><
manvolnum>5</
manvolnum></
citerefentry>,
<
citerefentry><
refentrytitle>
systemd.socket</
refentrytitle><
manvolnum>5</
manvolnum></
citerefentry>,
<
citerefentry><
refentrytitle>
systemd.target</
refentrytitle><
manvolnum>5</
manvolnum></
citerefentry>,
<
citerefentry><
refentrytitle>
systemd.slice</
refentrytitle><
manvolnum>5</
manvolnum></
citerefentry>,
<
citerefentry project='man-pages'><
refentrytitle>bootup</
refentrytitle><
manvolnum>7</
manvolnum></
citerefentry>,
<
citerefentry><
refentrytitle>systemd-fstab-generator</
refentrytitle><
manvolnum>8</
manvolnum></
citerefentry>