shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2025-03-08 08:58:27 +03:00
Code

Merge pull request #12075 from keszybz/two-docs

Browse Source 
Two small man page enhancements
This commit is contained in:
Lennart Poettering 2019-03-22 18:11:59 +01:00 committed by GitHub
commit 525ea273de
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
3 changed files with 35 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
NEWS
View File

@ -7,8 +7,8 @@ CHANGES WITH 242 in spe:
similar interfaces that do not have other identifying information,
the interface name is used as the basis for persistent seed for MAC
and IPv4LL addresses. The way that devices that were handled
previously is not changed, and this change is about covering devices
then previously by the "persistent" policy.
previously is not changed, and this change is about covering more
devices then previously by the "persistent" policy.
MACAddressPolicy=random may be used to force randomized MACs and
IPv4LL addresses for a device if desired.

37
man/bootup.xml
View File

@ -23,22 +23,29 @@
<refsect1>
<title>Description</title>
<para>A number of different components are involved in the system
boot. Immediately after power-up, the system BIOS will do minimal
hardware initialization, and hand control over to a boot loader
stored on a persistent storage device. This boot loader will then
invoke an OS kernel from disk (or the network). In the Linux case,
this kernel (optionally) extracts and executes an initial RAM disk
image (initrd), such as generated by
<para>A number of different components are involved in the boot of a Linux system. Immediately after
power-up, the system firmware will do minimal hardware initialization, and hand control over to a boot
loader (e.g.
<citerefentry><refentrytitle>systemd-boot</refentrytitle><manvolnum>7</manvolnum></citerefentry> or
<ulink url="https://www.gnu.org/software/grub/">GRUB</ulink>) stored on a persistent storage device. This
boot loader will then invoke an OS kernel from disk (or the network). On systems using EFI or other types
of firmware, this firmware may also load the kernel directly.</para>
<para>The kernel (optionally) mounts an in-memory file system, often generated by
<citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
which looks for the root file system (possibly using
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
for this). After the root file system is found and mounted, the
initrd hands over control to the host's system manager (such as
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>)
stored on the OS image, which is then responsible for probing all
remaining hardware, mounting all necessary file systems and
spawning all configured services.</para>
which looks for the root file system. Nowadays this is usually implemented as an initramfs — a compressed
archive which is extracted when the kernel boots up into a lightweight in-memory file system based on
tmpfs, but in the past normal file systems using an in-memory block device (ramdisk) were used, and the
name "initrd" is still used to describe both concepts. It's the boot loader or the firmware that loads
both the kernel and initrd/initramfs images into memory, but the kernel which interprets it as a file
system. <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry> may
be used to manage services in the initrd, similarly to the real system.</para>
<para>After the root file system is found and mounted, the initrd hands over control to the host's system
manager (such as
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>) stored in
the root file system, which is then responsible for probing all remaining hardware, mounting all
necessary file systems and spawning all configured services.</para>
<para>On shutdown, the system manager stops all services, unmounts
all file systems (detaching the storage technologies backing

18
man/systemd.service.xml
View File

@ -473,14 +473,18 @@
start-up failed, for example because any of the commands specified in <varname>ExecStart=</varname>,
<varname>ExecStartPre=</varname> or <varname>ExecStartPost=</varname> failed (and weren't prefixed with
<literal>-</literal>, see above) or timed out. Use <varname>ExecStopPost=</varname> to invoke commands when a
service failed to start up correctly and is shut down again. Also note that, service restart requests are
implemented as stop operations followed by start operations. This means that <varname>ExecStop=</varname> and
<varname>ExecStopPost=</varname> are executed during a service restart operation.</para>
service failed to start up correctly and is shut down again. Also note that the stop operation is always
performed if the service started successfully, even if the processes in the service terminated on their
own or were killed. The stop commands must be prepared to deal with that case. <varname>$MAINPID</varname>
will be unset if systemd knows that the main process exited by the time the stop commands are called.</para>
<para>It is recommended to use this setting for commands that communicate with the service requesting clean
termination. When the commands specified with this option are executed it should be assumed that the service is
still fully up and is able to react correctly to all commands. For post-mortem clean-up steps use
<varname>ExecStopPost=</varname> instead.</para></listitem>
<para>Service restart requests are implemented as stop operations followed by start operations. This
means that <varname>ExecStop=</varname> and <varname>ExecStopPost=</varname> are executed during a
service restart operation.</para>
<para>It is recommended to use this setting for commands that communicate with the service requesting
clean termination. For post-mortem clean-up steps use <varname>ExecStopPost=</varname> instead.
</para></listitem>
</varlistentry>
<varlistentry>