<para><filename>basic.target</filename>,
<filename>ctrl-alt-del.target</filename>,
<filename>dbus.service</filename>,
- <filename>dbus.target</filename>,
<filename>default.target</filename>,
<filename>display-manager.service</filename>,
<filename>emergency.target</filename>,
<filename>remote-fs.target</filename>,
<filename>rescue.target</filename>,
<filename>rpcbind.target</filename>,
- <filename>rtc-set.target</filename>,
+ <filename>time-sync.target</filename>,
<filename>runlevel2.target</filename>,
<filename>runlevel3.target</filename>,
<filename>runlevel4.target</filename>,
<filename>sockets.target</filename>,
<filename>swap.target</filename>,
<filename>sysinit.target</filename>,
- <filename>@SPECIAL_SYSLOG_SERVICE@</filename>,
<filename>syslog.target</filename>,
<filename>systemd-initctl.service</filename>,
<filename>systemd-initctl.socket</filename>,
up systemd will connect to it
and register its
service.</para>
-
- <para>Units should generally
- avoid depending on this unit
- directly and instead refer to
- the
- <filename>dbus.target</filename>
- unit instead, which pulls this
- one in directly or indirectly
- via socket-based activation.</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term><filename>dbus.target</filename></term>
- <listitem>
- <para>Administrators should
- ensure that this target pulls
- in a service unit with the
- name or alias of
- <filename>dbus.service</filename>
- (or a socket unit that
- activates this
- service).</para>
</listitem>
</varlistentry>
<varlistentry>
<filename>graphical.target</filename>.</para>
<para>The default unit systemd
starts at bootup can be
- overriden with the
- <varname>systemd.default=</varname>
+ overridden with the
+ <varname>systemd.unit=</varname>
kernel command line option.</para>
</listitem>
</varlistentry>
console. This unit is supposed
to be used with the kernel
command line option
- <varname>systemd.default=</varname>
+ <varname>systemd.unit=</varname>
and has otherwise little use.
</para>
</listitem>
all SysV init script service
units with an LSB header
referring to the
- <literal>$mail-transfer-argent</literal>
+ <literal>$mail-transfer-agent</literal>
or
<literal>$mail-transport-agent</literal>
facilities, for compatibility
</listitem>
</varlistentry>
<varlistentry>
- <term><filename>rtc-set.target</filename></term>
+ <term><filename>time-sync.target</filename></term>
<listitem>
<para>systemd automatically
adds dependencies of type
<term><filename>runlevel2.target</filename></term>
<listitem>
<para>This is a target that is
- called whever the SysV
+ called whenever the SysV
compatibility code asks for
runlevel 2. It is a good idea
to make this an alias for
<term><filename>runlevel3.target</filename></term>
<listitem>
<para>This is a target that is
- called whever the SysV
+ called whenever the SysV
compatibility code asks for
runlevel 3. It is a good idea
to make this an alias for
<term><filename>runlevel4.target</filename></term>
<listitem>
<para>This is a target that is
- called whever the SysV
+ called whenever the SysV
compatibility code asks for
runlevel 4. It is a good idea
to make this an alias for
<term><filename>runlevel5.target</filename></term>
<listitem>
<para>This is a target that is
- called whever the SysV
+ called whenever the SysV
compatibility code asks for
runlevel 5. It is a good idea
to make this an alias for
or b.</para>
</listitem>
</varlistentry>
- <varlistentry>
- <term><filename>@SPECIAL_SYSLOG_SERVICE@</filename></term>
- <listitem>
- <para>A special unit for the
- syslog daemon. As soon as
- this service is fully started
- up systemd will connect to it
- and use it for logging if it
- has been configured for
- that.</para>
-
- <para>Units should generally
- avoid depending on this unit
- directly and instead refer to
- the
- <filename>syslog.target</filename>
- unit instead, which pulls this
- one in directly or indirectly
- via socket-based activation.</para>
- </listitem>
- </varlistentry>
<varlistentry>
<term><filename>syslog.target</filename></term>
<listitem>
referring to the
<literal>$syslog</literal>
facility.</para>
-
- <para>Administrators should
- ensure that this target pulls
- in a service unit with the
- name or alias of
- <filename>@SPECIAL_SYSLOG_SERVICE@</filename>
- (or a socket unit that
- activates this
- service).</para>
</listitem>
</varlistentry>
<varlistentry>
</refsect1>
<refsect1>
- <title>Special Session Units</title>
+ <title>Special User Units</title>
- <para>When systemd runs as a service instance, the
+ <para>When systemd runs as a user instance, the
following special units are available, which have
similar definitions as their system counterparts:
<filename>default.target</filename>,
<listitem>
<para>A special service unit
for shutting down the
- session.</para>
+ user service manager.</para>
<para>Applications wanting to
- terminate the session should
- start this unit. If systemd
- receives SIGTERM or SIGINT
- when running as session daemon
- it will start this
- unit.</para>
+ terminate the user service
+ manager should start this
+ unit. If systemd receives
+ SIGTERM or SIGINT when running
+ as user service daemon it will
+ start this unit.</para>
<para>Normally, this pulls in
<filename>shutdown.target</filename>
which in turn should be
conflicted by all units that
want to be shut down on
- session exit.</para>
+ user service manager exit.</para>
</listitem>
</varlistentry>
</variablelist>
~ianmdlvl / elogind.git / blobdiff