mirror of
https://github.com/systemd/systemd
synced 2024-07-22 10:44:58 +00:00
Luca Boccassi
GitHub
commit
2e6606aaca
|
|
@ -1535,13 +1535,27 @@ Jan 12 10:46:45 example.com bluetoothd[8900]: gatt-time-server: Input/output err
|
|||
<term><command>kexec</command></term>
|
||||
|
||||
<listitem>
|
||||
<para>Shut down and reboot the system via <command>kexec</command>. This is equivalent to
|
||||
<command>systemctl start kexec.target --job-mode=replace-irreversibly --no-block</command>. This command is
|
||||
asynchronous; it will return after the reboot operation is enqueued, without waiting for it to
|
||||
complete.</para>
|
||||
<para>Shut down and reboot the system via <command>kexec</command>. This command will load a
|
||||
kexec kernel if one wasn't loaded yet or fail. A kernel may be loaded earlier by a separate step,
|
||||
this is particularly useful if a custom initrd or additional kernel commandline options are
|
||||
desired. The <option>--force</option> can be used to continue without a kexec kernel, i.e. to
|
||||
perform a normal reboot. The final reboot step is equivalent to
|
||||
<command>systemctl start kexec.target --job-mode=replace-irreversibly --no-block</command>.
|
||||
</para>
|
||||
|
||||
<para>This command honors <option>--force</option> and <option>--when=</option> in a similar way
|
||||
as <command>halt</command>.</para>
|
||||
<para>To load a kernel, an enumeration is performed following the
|
||||
<ulink url="https://uapi-group.org/specifications/specs/boot_loader_specification">Boot Loader Specification</ulink>,
|
||||
and the default boot entry is loaded. For this step to succeed, the system must be using UEFI
|
||||
and the boot loader entries must be configured appropriately. <command>bootctl list</command>
|
||||
may be used to list boot entries, see
|
||||
<citerefentry><refentrytitle>bootctl</refentrytitle><manvolnum>1</manvolnum></citerefentry>.
|
||||
</para>
|
||||
|
||||
<para>This command is asynchronous; it will return after the reboot operation is enqueued,
|
||||
without waiting for it to complete.</para>
|
||||
|
||||
<para>This command honors <option>--force</option> and <option>--when=</option> similarly
|
||||
to <command>halt</command>.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
|
||||
|
|
|
|||
|
|
@ -185,15 +185,16 @@
|
|||
</tgroup>
|
||||
</table>
|
||||
|
||||
<para>The <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename> and
|
||||
<filename>/var/tmp/</filename> partitions may be encrypted in LUKS format. In this case, a device mapper
|
||||
device is set up under the names <filename>/dev/mapper/home</filename>,
|
||||
<filename>/dev/mapper/srv</filename>, <filename>/dev/mapper/var</filename> and
|
||||
<filename>/dev/mapper/tmp</filename>. Note that this might create conflicts if the same partition is
|
||||
listed in <filename>/etc/crypttab</filename> with a different device mapper device name.</para>
|
||||
<para>The <filename>/home/</filename>, <filename>/srv/</filename>, <filename>/var/</filename>,
|
||||
<filename>/var/tmp/</filename> and swap partitions may be encrypted in LUKS format. In this case, a
|
||||
device mapper device is set up under the names <filename>/dev/mapper/home</filename>,
|
||||
<filename>/dev/mapper/srv</filename>, <filename>/dev/mapper/var</filename>,
|
||||
<filename>/dev/mapper/tmp</filename> or <filename>/dev/mapper/swap</filename>. Note that this might
|
||||
create conflicts if the same partition is listed in <filename>/etc/crypttab</filename> with a different
|
||||
device mapper device name.</para>
|
||||
|
||||
<para>When systemd is running in the initrd the <filename>/</filename> partition may be encrypted in LUKS
|
||||
format as well. In this case, a device mapper device is set up under the name
|
||||
<para>When systemd is running in the initrd the <filename>/</filename> partition may be encrypted with
|
||||
LUKS as well. In this case, a device mapper device is set up under the name
|
||||
<filename>/dev/mapper/root</filename>, and a <filename>sysroot.mount</filename> is set up that mounts the
|
||||
device under <filename>/sysroot</filename>. For more information, see
|
||||
<citerefentry><refentrytitle>bootup</refentrytitle><manvolnum>7</manvolnum></citerefentry>.
|
||||
|
|
|
|||
|
|
@ -84,15 +84,17 @@
|
|||
existing partition of a specific type is then assigned the second configuration file declaring the same
|
||||
type, and so on. After this iterative assigning is complete any left-over existing partitions that have
|
||||
no matching configuration file are considered "foreign" and left as they are. And any configuration
|
||||
files for which no partition currently exists are understood as a request to create such a
|
||||
partition.</para></listitem>
|
||||
files for which no partition currently exists are understood as a request to create such a partition.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>Taking the size constraints and weights declared in the configuration files into
|
||||
account, all partitions that shall be created are now allocated to the disk, taking up all free space,
|
||||
always respecting the size and padding requests. Similarly, existing partitions that should be grown
|
||||
are grown. New partitions are always appended to the end of the partition table, taking the first
|
||||
partition table slot whose index is greater than the indexes of all existing partitions. Partition
|
||||
table slots are never reordered and thus partition numbers are ensured to remain stable. Note that this
|
||||
<listitem><para>Partitions that shall be created are now allocated on the disk, taking the size
|
||||
constraints and weights declared in the configuration files into account. Free space is used within the
|
||||
limits set by size and padding requests. In addition, existing partitions that should be grown are
|
||||
grown. New partitions are always appended to the end of the partition table, taking the first partition
|
||||
table slot whose index is greater than the indexes of all existing partitions. Partitions are never
|
||||
reordered and thus partition numbers remain stable. When partitions are created, they are placed in the
|
||||
smallest area of free space that is large enough to satisfy the size and padding limits. This means
|
||||
that partitions might have different order on disk than in the parition table. Note that this
|
||||
allocation happens in memory only, the partition table on disk is not updated yet.</para></listitem>
|
||||
|
||||
<listitem><para>All existing partitions for which configuration files exist and which currently have no
|
||||
|
|
|
|||
|
|
@ -26,30 +26,33 @@
|
|||
<refsect1>
|
||||
<title>Description</title>
|
||||
|
||||
<para>A unit configuration file whose name ends in
|
||||
<literal>.target</literal> encodes information about a target unit
|
||||
of systemd, which is used for grouping units and as well-known
|
||||
synchronization points during start-up.</para>
|
||||
<para>A unit configuration file whose name ends in <literal>.target</literal> encodes information about a
|
||||
target unit of systemd. Target units are used to group units and to set synchronization points for
|
||||
ordering dependencies with other unit files.</para>
|
||||
|
||||
<para>This unit type has no specific options. See
|
||||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
||||
for the common options of all unit configuration files. The common
|
||||
configuration items are configured in the generic [Unit] and
|
||||
[Install] sections. A separate [Target] section does not exist,
|
||||
since no target-specific options may be configured.</para>
|
||||
<citerefentry><refentrytitle>systemd.unit</refentrytitle><manvolnum>5</manvolnum></citerefentry> for the
|
||||
common options of all unit configuration files. The common configuration items are configured in the
|
||||
generic [Unit] and [Install] sections. A separate [Target] section does not exist, since no
|
||||
target-specific options may be configured.</para>
|
||||
|
||||
<para>Target units do not offer any additional functionality on
|
||||
top of the generic functionality provided by units. They exist
|
||||
merely to group units via dependencies (useful as boot targets),
|
||||
and to establish standardized names for synchronization points
|
||||
used in dependencies between units. Among other things, target
|
||||
units are a more flexible replacement for SysV runlevels in the
|
||||
classic SysV init system. (And for compatibility reasons special
|
||||
target units such as <filename>runlevel3.target</filename> exist
|
||||
which are used by the SysV runlevel compatibility code in systemd.
|
||||
See
|
||||
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
for details).</para>
|
||||
<para>Target units do not offer any additional functionality on top of the generic functionality provided
|
||||
by units. They merely group units, allowing a single target name to be used in <varname>Wants=</varname>
|
||||
and <varname>Requires=</varname> settings to establish a dependency on a set of units defined by the
|
||||
target, and in <varname>Before=</varname> and <varname>After=</varname> settings to establish ordering.
|
||||
Targets establish standardized names for synchronization points during boot and shutdown. Importantly,
|
||||
see <citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>
|
||||
for examples and descriptions of standard systemd targets.</para>
|
||||
|
||||
<para>Target units provide a more flexible replacement for SysV runlevels in the classic SysV init
|
||||
system. For compatibility reasons special target units such as <filename>runlevel3.target</filename>
|
||||
exist which are used by the SysV runlevel compatibility code in systemd, see
|
||||
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry> for
|
||||
details.</para>
|
||||
|
||||
<para>Note that a target unit file must not be empty, lest it be considered a masked unit. It is
|
||||
recommended to provide a [Unit] section which includes informative <varname>Description=</varname> and
|
||||
<varname>Documentation=</varname> options.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
|
@ -68,14 +71,18 @@
|
|||
<varname>DefaultDependencies=no</varname> is set:</para>
|
||||
|
||||
<itemizedlist>
|
||||
<listitem><para>Target units will automatically complement all
|
||||
configured dependencies of type <varname>Wants=</varname> or
|
||||
<varname>Requires=</varname> with dependencies of type
|
||||
<varname>After=</varname> unless <varname>DefaultDependencies=no</varname>
|
||||
is set in the specified units. Note that <varname>Wants=</varname> or
|
||||
<varname>Requires=</varname> must be defined in the target unit itself — if
|
||||
you for example define <varname>Wants=</varname>some.target in
|
||||
some.service, the automatic ordering will not be added.</para></listitem>
|
||||
<listitem><para>Target units will automatically complement all configured dependencies of type
|
||||
<varname>Wants=</varname> or <varname>Requires=</varname> with dependencies of type
|
||||
<varname>After=</varname> unless <varname>DefaultDependencies=no</varname> is set in the specified
|
||||
units.</para>
|
||||
|
||||
<para>Note that the reverse is not true. For example, defining <option>Wants=that.target</option> in
|
||||
<filename index='false'>some.service</filename> will not automatically add the
|
||||
<option>After=that.target</option> ordering dependency for <filename>some.service</filename>.
|
||||
Instead, <filename>some.service</filename> should use the primary synchronization function of target
|
||||
type units, by setting a specific <option>After=that.target</option> or
|
||||
<option>Before=that.target</option> ordering dependency in its .service unit file.
|
||||
</para></listitem>
|
||||
|
||||
<listitem><para>Target units automatically gain <varname>Conflicts=</varname>
|
||||
and <varname>Before=</varname> dependencies against
|
||||
|
|
|
|||
Loading…
Reference in a new issue