<?xml version='1.0'?> <!--*-nxml-*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
+<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-
-<!--
- SPDX-License-Identifier: LGPL-2.1+
-
- This file is part of systemd.
-
- Copyright 2012 Lennart Poettering
-
- systemd is free software; you can redistribute it and/or modify it
- under the terms of the GNU Lesser General Public License as published by
- the Free Software Foundation; either version 2.1 of the License, or
- (at your option) any later version.
-
- systemd is distributed in the hope that it will be useful, but
- WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- Lesser General Public License for more details.
-
- You should have received a copy of the GNU Lesser General Public License
- along with systemd; If not, see <http://www.gnu.org/licenses/>.
--->
+<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="bootup">
<refentryinfo>
<title>bootup</title>
<productname>systemd</productname>
-
- <authorgroup>
- <author>
- <contrib>Developer</contrib>
- <firstname>Lennart</firstname>
- <surname>Poettering</surname>
- <email>lennart@poettering.net</email>
- </author>
- </authorgroup>
</refentryinfo>
<refmeta>
<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
other units. Units near the top are started before units nearer to
the bottom of the chart.</para>
-<programlisting>local-fs-pre.target
- |
- v
-(various mounts and (various swap (various cryptsetup
- fsck services...) devices...) devices...) (various low-level (various low-level
- | | | services: udevd, API VFS mounts:
- v v v tmpfiles, random mqueue, configfs,
- local-fs.target swap.target cryptsetup.target seed, sysctl, ...) debugfs, ...)
- | | | | |
- \__________________|_________________ | ___________________|____________________/
- \|/
- v
- sysinit.target
- |
- ____________________________________/|\________________________________________
- / | | | \
- | | | | |
- v v | v v
- (various (various | (various rescue.service
- timers...) paths...) | sockets...) |
- | | | | v
- v v | v <emphasis>rescue.target</emphasis>
- timers.target paths.target | sockets.target
- | | | |
- v \_________________ | ___________________/
- \|/
- v
- basic.target
- |
- ____________________________________/| emergency.service
- / | | |
- | | | v
- v v v <emphasis>emergency.target</emphasis>
- display- (various system (various system
- manager.service services services)
- | required for |
- | graphical UIs) v
- | | <emphasis>multi-user.target</emphasis>
- | | |
- \_________________ | _________________/
- \|/
- v
- <emphasis>graphical.target</emphasis></programlisting>
+ <!-- note: do not use unicode ellipsis here, because docbook will replace that
+ with three dots anyway, messing up alignment -->
+<programlisting> cryptsetup-pre.target
+ |
+(various low-level v
+ API VFS mounts: (various cryptsetup devices...)
+ mqueue, configfs, | |
+ debugfs, ...) v |
+ | cryptsetup.target |
+ | (various swap | | remote-fs-pre.target
+ | devices...) | | | |
+ | | | | | v
+ | v local-fs-pre.target | | | (network file systems)
+ | swap.target | | v v |
+ | | v | remote-cryptsetup.target |
+ | | (various low-level (various mounts and | | |
+ | | services: udevd, fsck services...) | | remote-fs.target
+ | | tmpfiles, random | | | /
+ | | seed, sysctl, ...) v | | /
+ | | | local-fs.target | | /
+ | | | | | | /
+ \____|______|_______________ ______|___________/ | /
+ \ / | /
+ v | /
+ sysinit.target | /
+ | | /
+ ______________________/|\_____________________ | /
+ / | | | \ | /
+ | | | | | | /
+ v v | v | | /
+ (various (various | (various | |/
+ timers...) paths...) | sockets...) | |
+ | | | | | |
+ v v | v | |
+timers.target paths.target | sockets.target | |
+ | | | | v |
+ v \_______ | _____/ rescue.service |
+ \|/ | |
+ v v |
+ basic.target <emphasis>rescue.target</emphasis> |
+ | |
+ ________v____________________ |
+ / | \ |
+ | | | |
+ v v v |
+ display- (various system (various system |
+ manager.service services services) |
+ | required for | |
+ | graphical UIs) v v
+ | | <emphasis>multi-user.target</emphasis>
+emergency.service | | |
+ | \_____________ | _____________/
+ v \|/
+<emphasis>emergency.target</emphasis> v
+ <emphasis>graphical.target</emphasis></programlisting>
<para>Target units that are commonly used as boot targets are
<emphasis>emphasized</emphasis>. These units are good choices as
later in boot.</para>
</refsect1>
+ <refsect1>
+ <title>User manager startup</title>
+
+ <para>The system manager starts the <filename>user@<replaceable>uid</replaceable>.service</filename> unit
+ for each user, which launches a separate unprivileged instance of <command>systemd</command> for each
+ user — the user manager. Similarly to the system manager, the user manager starts units which are pulled
+ in by <filename>default.target</filename>. The following chart is a structural overview of the well-known
+ user units. For non-graphical sessions, <filename>default.target</filename> is used. Whenever the user
+ logs into a graphical session, the login manager will start the
+ <filename>graphical-session.target</filename> target that is used to pull in units required for the
+ grahpical session. A number of targets (shown on the right side) are started when specific hardware is
+ available to the user.</para>
+
+<programlisting>
+ (various (various (various
+ timers...) paths...) sockets...) (sound devices)
+ | | | |
+ v v v v
+ timers.target paths.target sockets.target sound.target
+ | | |
+ \______________ _|_________________/ (bluetooth devices)
+ \ / |
+ V v
+ basic.target bluetooth.target
+ |
+ __________/ \_______ (smartcard devices)
+ / \ |
+ | | v
+ | v smartcard.target
+ v graphical-session-pre.target
+ (various user services) | (printers)
+ | v |
+ | (services for the graphical sesion) v
+ | | printer.target
+ v v
+ <emphasis>default.target</emphasis> graphical-session.target</programlisting>
+
+ </refsect1>
+
<refsect1>
<title>Bootup in the Initial RAM Disk (initrd)</title>
<para>The initial RAM disk implementation (initrd) can be set up
using systemd as well. In this case, boot up inside the initrd
follows the following structure.</para>
- <para>The default target in the initrd is
+ <para>systemd detects that it is run within an initrd by checking
+ for the file <filename>/etc/initrd-release</filename>.
+ The default target in the initrd is
<filename>initrd.target</filename>. The bootup process begins
identical to the system manager bootup (see above) until it
reaches <filename>basic.target</filename>. From there, systemd
v v v v
<emphasis>reboot.target</emphasis> <emphasis>poweroff.target</emphasis> <emphasis>halt.target</emphasis> <emphasis>kexec.target</emphasis></programlisting>
- <para>Commonly used system shutdown targets are
- <emphasis>emphasized</emphasis>.</para>
+ <para>Commonly used system shutdown targets are <emphasis>emphasized</emphasis>.</para>
+
+ <para>Note that
+ <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+ <filename>systemd-reboot.service</filename>, <filename>systemd-poweroff.service</filename> and
+ <filename>systemd-kexec.service</filename> will transition the system and server manager (PID 1) into the second
+ phase of system shutdown (implemented in the <filename>systemd-shutdown</filename> binary), which will unmount any
+ remaining file systems, kill any remaining processes and release any other remaining resources, in a simple and
+ robust fashion, without taking any service or unit concept into account anymore. At that point, regular
+ applications and resources are generally terminated and released already, the second phase hence operates only as
+ safety net for everything that couldn't be stopped or released for some reason during the primary, unit-based
+ shutdown phase described above.</para>
</refsect1>
<refsect1>
<citerefentry project='man-pages'><refentrytitle>boot</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.special</refentrytitle><manvolnum>7</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd.target</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
+ <citerefentry><refentrytitle>systemd-halt.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry project='die-net'><refentrytitle>dracut</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</para>
</refsect1>
projects / thirdparty / systemd.git / blobdiff