commit 9477b03e1a8e5fd50c250f9b9cb646dca320f5b2
Author: Jack Reed <jreed(a)redhat.com>
Date: Thu Nov 1 15:59:12 2012 +1000
Tweaks to Boot Process, Init, and Shutdown
en-US/Boot_Init_Shutdown.xml | 1523 +++++++++++++++++++++++-------------------
1 files changed, 842 insertions(+), 681 deletions(-)
---
diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
index 5713bee..f86ce87 100644
--- a/en-US/Boot_Init_Shutdown.xml
+++ b/en-US/Boot_Init_Shutdown.xml
@@ -4,422 +4,437 @@
%BOOK_ENTITIES;
]>
<appendix id="ch-boot-init-shutdown">
- <title>Boot Process, Init, and Shutdown</title>
- <indexterm significance="normal">
- <primary>boot process</primary>
-
- </indexterm>
- <para>
- An important and powerful aspect of Fedora is the open, user-configurable method it
uses for starting the operating system. Users are free to configure many aspects of the
boot process, including specifying the programs launched at boot-time. Similarly, system
shutdown gracefully terminates processes in an organized and configurable way, although
customization of this process is rarely required.
- </para>
- <para>
- Understanding how the boot and shutdown processes work not only allows customization,
but also makes it easier to troubleshoot problems related to starting or shutting down the
system.
+ <title>Boot Process, Init, and Shutdown</title>
+ <indexterm significance="normal">
+ <primary>boot process</primary>
+
+ </indexterm>
+ <para>
+ An important and powerful aspect of Fedora is the open, user-configurable method it
uses for starting the operating system. Users are free to configure many aspects of the
boot process, including specifying the programs launched at boot-time. Similarly, system
shutdown gracefully terminates processes in an organized and configurable way, although
customization of this process is rarely required.
+ </para>
+ <para>
+ Understanding how the boot and shutdown processes work not only allows customization,
but also makes it easier to troubleshoot problems related to starting or shutting down the
system.
+ </para>
+ <section id="s1-boot-process-basics">
+ <title>The Boot Process</title>
+ <indexterm significance="normal">
+ <primary>boot process</primary>
+ <secondary>stages of</secondary>
+
+ </indexterm>
+ <para>
+ Below are the basic stages of the boot process:
</para>
- <section id="s1-boot-process-basics">
- <title>The Boot Process</title>
- <indexterm significance="normal">
- <primary>boot process</primary>
- <secondary>stages of</secondary>
-
- </indexterm>
- <para>
- Below are the basic stages of the boot process:
+ <orderedlist continuation="restarts" inheritnum="ignore">
+ <listitem>
+ <para>
+ The system loads and runs a boot loader. The specifics of this process depend on the
system architecture. For example:
</para>
- <orderedlist continuation="restarts" inheritnum="ignore">
- <listitem>
- <para>
- The system loads and runs a boot loader. The specifics of this process depend on the
system architecture. For example:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- BIOS-based x86 systems run a first-stage boot loader from the MBR of the primary
hard disk that, in turn, loads an additional boot loader,
<application>GRUB</application>.
- </para>
- </listitem>
- <listitem>
- <para>
- UEFI-based x86 systems mount an EFI System Partition that contains a version of
the <application>GRUB</application> boot loader. The EFI boot manager loads
and runs <application>GRUB</application> as an EFI application.
- </para>
- </listitem>
- </itemizedlist>
- </listitem>
- <listitem>
- <para>
- The boot loader loads the kernel into memory, which in turn loads any necessary
modules and mounts the root partition read-only.
- </para>
-
- </listitem>
- <listitem>
- <para>
- The kernel transfers control of the boot process to the
<command>/sbin/init</command> program.
- </para>
-
- </listitem>
- <listitem>
- <para>
- The <command>/sbin/init</command> program loads all services and
user-space tools, and mounts all partitions listed in
<filename>/etc/fstab</filename>.
- </para>
-
- </listitem>
- <listitem>
- <para>
- The user is presented with a login screen for the freshly booted Linux system.
- </para>
-
- </listitem>
-
- </orderedlist>
- <para>
- Because configuration of the boot process is more common than the customization of the
shutdown process, the remainder of this chapter discusses in detail how the boot process
works and how it can be customized to suite specific needs.
+ <itemizedlist>
+ <listitem>
+ <para>
+ BIOS-based x86 systems run a first-stage boot loader from the MBR of the primary
hard disk that, in turn, loads an additional boot loader,
<application>GRUB</application>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ UEFI-based x86 systems mount an EFI System Partition that contains a version of the
<application>GRUB</application> boot loader. The EFI boot manager loads and
runs <application>GRUB</application> as an EFI application.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ <listitem>
+ <para>
+ The boot loader loads the kernel and a small, read-only filesystem into memory. This
filesystem, or initramfs, contains all the tools required for the kernel to continue the
boot process.
</para>
-
- </section>
+
+ </listitem>
+ <listitem>
+ <para>
+ The kernel transfers control of the boot process to the system daemon,
<application>systemd</application>.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ <application>systemd</application> loads needed services and user-space
tools, and mounts filesystems listed in <filename>/etc/fstab</filename>.
+ </para>
+
+ </listitem>
+ <listitem>
+ <para>
+ The user is presented with a login screen for the freshly booted Linux system.
+ </para>
+
+ </listitem>
+
+ </orderedlist>
+ <para>
+ Because configuration of the boot process is more common than the customization of the
shutdown process, the remainder of this chapter discusses in detail how the boot process
works and how it can be customized to suit specific needs.
+ </para>
+
+ </section>
+
+ <section id="s1-boot-init-shutdown-process">
+ <title>A Detailed Look at the Boot Process</title>
+ <indexterm significance="normal">
+ <primary>boot process</primary>
+ <secondary>for x86</secondary>
+
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>boot process</primary>
+ <seealso>boot loaders</seealso>
+
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>boot process</primary>
+ <secondary>stages of</secondary>
+
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>Master Boot Record</primary>
+ <see>MBR</see>
+
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>MBR</primary>
+ <secondary>definition of</secondary>
+ <seealso>boot process</seealso>
+
+ </indexterm>
+ <para>
+ The beginning of the boot process varies depending on the hardware platform being
used. However, once the kernel is found and loaded by the boot loader, the default boot
process is identical across all architectures. This chapter focuses primarily on the x86
architecture.
+ </para>
- <section id="s1-boot-init-shutdown-process">
- <title>A Detailed Look at the Boot Process</title>
- <indexterm significance="normal">
- <primary>boot process</primary>
- <secondary>for x86</secondary>
-
+ <section id="sect-firmware_interface">
+ <title>The firmware interface</title>
+ <section id="s2-boot-init-shutdown-bios">
+ <title>BIOS-based x86 systems</title>
+ <indexterm significance="normal">
+ <primary>Basic Input/Output System</primary>
+ <see>BIOS</see>
</indexterm>
- <indexterm significance="normal">
- <primary>boot process</primary>
- <seealso>boot loaders</seealso>
-
+ <indexterm significance="normal">
+ <primary>BIOS</primary>
+ <secondary>definition of</secondary>
+ <seealso>boot process</seealso>
</indexterm>
- <indexterm significance="normal">
- <primary>boot process</primary>
- <secondary>stages of</secondary>
-
+ <indexterm significance="normal">
+ <primary>Master Boot Record</primary>
+ <see>MBR</see>
</indexterm>
- <indexterm significance="normal">
- <primary>Master Boot Record</primary>
- <see>MBR</see>
-
+ <indexterm significance="normal">
+ <primary>MBR</primary>
+ <secondary>definition of</secondary>
+ <seealso>boot loaders</seealso>
</indexterm>
- <indexterm significance="normal">
- <primary>MBR</primary>
- <secondary>definition of</secondary>
- <seealso>boot process</seealso>
-
+ <indexterm>
+ <primary>GUID Partition Table</primary>
+ <see>GPT</see>
</indexterm>
- <para>
- The beginning of the boot process varies depending on the hardware platform being
used. However, once the kernel is found and loaded by the boot loader, the default boot
process is identical across all architectures. This chapter focuses primarily on the x86
architecture.
+ <indexterm significance="normal">
+ <primary>GPT</primary>
+ <secondary>definition of</secondary>
+ </indexterm>
+ <para>
+ The <firstterm>Basic Input/Output System</firstterm> (BIOS) is a firmware
interface that controls not only the first step of the boot process, but also provides the
lowest level interface to peripheral devices. On x86 systems equipped with BIOS, the
program is written into read-only, permanent memory and is always available for use. When
the system boots, the processor looks at the end of system memory for the BIOS program,
and runs it.
</para>
-
- <section id="sect-firmware_interface">
- <title>The firmware interface</title>
- <section id="s2-boot-init-shutdown-bios">
- <title>BIOS-based x86 systems</title>
- <indexterm significance="normal">
- <primary>Basic Input/Output System</primary>
- <see>BIOS</see>
- </indexterm>
- <indexterm significance="normal">
- <primary>BIOS</primary>
- <secondary>definition of</secondary>
- <seealso>boot process</seealso>
- </indexterm>
- <indexterm significance="normal">
- <primary>Master Boot Record</primary>
- <see>MBR</see>
- </indexterm>
- <indexterm significance="normal">
- <primary>MBR</primary>
- <secondary>definition of</secondary>
- <seealso>boot loaders</seealso>
- </indexterm>
- <para>
- The <firstterm>Basic Input/Output System</firstterm> (BIOS) is a
firmware interface that controls not only the first step of the boot process, but also
provides the lowest level interface to peripheral devices. On x86 systems equipped with
BIOS, the program is written into read-only, permanent memory and is always available for
use. When the system boots, the processor looks at the end of system memory for the BIOS
program, and runs it.
- </para>
- <para>
- Once loaded, the BIOS tests the system, looks for and checks peripherals, and then
locates a valid device with which to boot the system. Usually, it checks any optical
drives or USB storage devices present for bootable media, then, failing that, looks to the
system's hard drives. In most cases, the order of the drives searched while booting is
controlled with a setting in the BIOS, and it looks on the master IDE on the primary IDE
bus or for a SATA device with a boot flag set. The BIOS then loads into memory whatever
program is residing in the first sector of this device, called the <firstterm>Master
Boot Record</firstterm> (MBR). The MBR is only 512 bytes in size and contains
machine code instructions for booting the machine, called a boot loader, along with the
partition table. Once the BIOS finds and loads the boot loader program into memory, it
yields control of the boot process to it.
- </para>
- <para>
- This first-stage boot loader is a small machine code binary on the MBR. Its sole job
is to locate the second stage boot loader (<application>GRUB</application>)
and load the first part of it into memory.
- </para>
- </section>
- <section id="s2-boot-init-shutdown-uefi">
- <title>UEFI-based x86 systems</title>
- <indexterm significance="normal">
- <primary>Extensible Firmware Interface shell</primary>
- <see>EFI shell</see>
- </indexterm>
- <indexterm significance="normal">
- <primary>EFI shell</primary>
- <seealso>boot process</seealso>
- </indexterm>
- <indexterm significance="normal">
- <primary>boot process</primary>
- <secondary>stages of</secondary>
- <tertiary>EFI shell</tertiary>
- </indexterm>
- <para>
- The <firstterm>Unified Extensible Firmware Interface</firstterm> (UEFI)
is designed, like BIOS, to control the boot process (through <firstterm>boot
services</firstterm>) and to provide an interface between system firmware and an
operating system (through <firstterm>runtime services</firstterm>). Unlike
BIOS, it features its own architecture, independent of the CPU, and its own device
drivers. UEFI can mount partitions and read certain file systems.
- </para>
- <para>
- When an x86 computer equipped with UEFI boots, the interface searches the system
storage for a partition labeled with a specific <firstterm>globally unique
identifier</firstterm> (GUID) that marks it as the <firstterm>EFI System
Partition</firstterm> (ESP). This partition contains applications compiled for the
EFI architecture, which might include bootloaders for operating systems and utility
software. UEFI systems include an <firstterm>EFI boot manager</firstterm> that
can boot the system from a default configuration, or prompt a user to choose an operating
system to boot. When a bootloader is selected, manually or automatically, UEFI reads it
into memory and yields control of the boot process to it.
- </para>
- </section>
- </section>
-
- <section id="s2-boot-init-shutdown-loader">
- <title>The Boot Loader</title>
- <section id="s2-boot-init-shutdown-loader-bios">
- <title>The GRUB boot loader for x86 systems</title>
- <indexterm significance="normal">
- <primary>boot process</primary>
- <secondary>stages of</secondary>
- <tertiary>boot loader</tertiary>
- </indexterm>
- <indexterm significance="normal">
- <primary>GRUB</primary>
- <secondary>role in boot process</secondary>
- </indexterm>
- <indexterm significance="normal">
- <primary>GRUB</primary>
- <seealso>boot loaders</seealso>
- </indexterm>
-
- <para>
- The system loads GRUB into memory, as directed by either a first-stage bootloader in
the case of systems equipped with BIOS, or read directly from an EFI System Partition in
the case of systems equipped with UEFI.
- </para>
- <para>
- GRUB has the advantage of being able to read ext2, ext3, and ext4 <footnote>
<para>
- GRUB reads ext3 and ext4 file systems as ext2, disregarding the journal file.
- </para>
- </footnote> partitions and load its configuration file —
<filename>/boot/grub2/grub.cfg</filename> (for BIOS) or
<filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) — at
boot time. Refer to <xref linkend="s1-grub-configfile" /> for information
on how to edit this file.
- </para>
- <important>
- <title>Important — Supported file systems</title>
- <para>
- The <application>GRUB</application> bootloader in
Fedora &PRODVER; supports ext2, ext3, and ext4 file systems. It does not
support other file systems such as VFAT, Btrfs or XFS. Furthermore,
<application>GRUB</application> does not support LVM.
- </para>
-
- </important>
- <para>
- Once the second stage boot loader is in memory, it presents the user with a
graphical screen showing the different operating systems or kernels it has been configured
to boot (when you update the kernel, the boot loader configuration file is updated
automatically). On this screen a user can use the arrow keys to choose which operating
system or kernel they wish to boot and press <keycap>Enter</keycap>. If no key
is pressed, the boot loader loads the default selection after a configurable period of
time has passed.
- </para>
- <para>
- Once the second stage boot loader has determined which kernel to boot, it locates
the corresponding kernel binary in the <filename>/boot/</filename> directory.
The kernel binary is named using the following format —
<filename>/boot/vmlinuz-<replaceable><kernel-version></replaceable></filename>
file (where
<filename><replaceable><kernel-version></replaceable></filename>
corresponds to the kernel version specified in the boot loader's settings).
- </para>
- <para>
- For instructions on using the boot loader to supply command line arguments to the
kernel, refer to <xref linkend="ch-grub" />. For information on changing
the runlevel at the boot loader prompt, refer <xref
linkend="s1-grub-runlevels" />.
- </para>
- <para>
- The boot loader then places one or more appropriate
<filename>initramfs</filename> images into memory. The
<filename>initramfs</filename> is used by the kernel to load drivers and
modules necessary to boot the system. This is particularly important if SCSI hard drives
are present or if the systems use the ext3 or ext4 file system.
- </para>
- <para>
- Once the kernel and the <filename>initramfs</filename> image(s) are
loaded into memory, the boot loader hands control of the boot process to the kernel.
- </para>
- <para>
- For a more detailed overview of the GRUB boot loader, refer to <xref
linkend="ch-grub" />.
- </para>
-
- </section>
-
- <section id="s3-boot-init-shutdown-other-architectures">
- <title>Boot Loaders for Other Architectures</title>
- <para>
- Once the kernel loads and hands off the boot process to the
<command>init</command> command, the same sequence of events occurs on every
architecture. So the main difference between each architecture's boot process is in
the application used to find and load the kernel.
- </para>
- <para>
- For example, the IBM eServer pSeries architecture uses
<application>yaboot</application>, and the IBM System z systems use
the z/IPL boot loader.
- </para>
- </section>
+ <para>
+ Once loaded, the BIOS tests the system, looks for and checks peripherals, and then
locates a valid device with which to boot the system. Usually, it checks any optical
drives or USB storage devices present for bootable media, then, failing that, looks to the
system's hard drives. In most cases, the order of the drives searched while booting is
controlled with a setting in the BIOS, and it looks for bootable media in the specified
order.
+ </para>
+ <para>
+ A disk may either have a <firstterm>Master Boot Record</firstterm> (MBR)
or a <firstterm>GUID Partition Table</firstterm> (GPT). The
<systemitem>MBR</systemitem> is only 512 bytes in size and contains machine
code instructions for booting the machine, called a boot loader, along with the partition
table. The newer <systemitem>GPT</systemitem> serves the same role and allows
for more and larger partitions, but is generally used on newer
<systemitem>UEFI</systemitem> systems. Once the BIOS finds and loads the boot
loader program into memory, it yields control of the boot process to it.
+ </para>
+ <para>
+ This first-stage boot loader is a small machine code binary on the MBR. Its sole job
is to locate the second stage boot loader (<application>GRUB</application>)
and load the first part of it into memory.
+ </para>
+ </section>
+ </section>
+ <section id="s2-boot-init-shutdown-uefi">
+ <title>UEFI-based x86 systems</title>
+ <indexterm significance="normal">
+ <primary>Extensible Firmware Interface shell</primary>
+ <see>EFI shell</see>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>EFI shell</primary>
+ <seealso>boot process</seealso>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>boot process</primary>
+ <secondary>stages of</secondary>
+ <tertiary>EFI shell</tertiary>
+ </indexterm>
+ <para>
+ The <firstterm>Unified Extensible Firmware Interface</firstterm> (UEFI) is
designed, like BIOS, to control the boot process (through <firstterm>boot
services</firstterm>) and to provide an interface between system firmware and an
operating system (through <firstterm>runtime services</firstterm>). Unlike
BIOS, it features its own architecture, independent of the CPU, and its own device
drivers. UEFI can mount partitions and read certain file systems.
+ </para>
+ <para>
+ When an x86 computer equipped with UEFI boots, the interface searches the system
storage for a partition labeled with a specific <firstterm>globally unique
identifier</firstterm> (GUID) that marks it as the <firstterm>EFI System
Partition</firstterm> (ESP). This partition contains applications compiled for the
EFI architecture, which might include bootloaders for operating systems and utility
software. UEFI systems include an <firstterm>EFI boot manager</firstterm> that
can boot the system from a default configuration, or prompt a user to choose an operating
system to boot. When a bootloader is selected, manually or automatically, UEFI reads it
into memory and yields control of the boot process to it.
+ </para>
+ </section>
+ </section>
+ <section id="s2-boot-init-shutdown-loader">
+ <title>The Boot Loader</title>
+ <section id="s2-boot-init-shutdown-loader-bios">
+ <title>The GRUB boot loader for x86 systems</title>
+ <indexterm significance="normal">
+ <primary>boot process</primary>
+ <secondary>stages of</secondary>
+ <tertiary>boot loader</tertiary>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>GRUB</primary>
+ <secondary>role in boot process</secondary>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>GRUB</primary>
+ <seealso>boot loaders</seealso>
+ </indexterm>
+ <para>
+ The system loads GRUB into memory, as directed by either a first-stage bootloader
in the case of systems equipped with BIOS, or read directly from an EFI System Partition
in the case of systems equipped with UEFI.
+ </para>
+ <para>
+ <application>GRUB</application> version 2 has the advantage of being
able to read a variety of open filesystems, as well as virtual devices such as
<application>mdadm</application> RAID arrays and
<application>LVM</application> .
+ </para>
+ <para>
+ GRUB mounts a designated partition and load its configuration file —
<filename>/boot/grub2/grub.cfg</filename> (for BIOS) or
<filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) — at
boot time. Refer to <xref linkend="s1-grub-configfile" /> for information
on how to edit this file.
+ </para>
+ <para>
+ Once the second stage boot loader is in memory, it presents the user with a
graphical screen showing the different operating systems or kernels it has been configured
to boot (when you update the kernel, the boot loader configuration file is updated
automatically). On this screen a user can use the arrow keys to choose which operating
system or kernel they wish to boot and press <keycap>Enter</keycap>.
Typically, if no key is pressed, the boot loader loads the default selection after a
configurable period of time has passed.
+ </para>
+ <para>
+ Once the second stage boot loader has determined which kernel to boot, it locates
the corresponding kernel binary in the <filename>/boot/</filename> directory.
The kernel binary is named using the following format —
<filename>/boot/vmlinuz-<replaceable><kernel-version></replaceable></filename>
file (where
<filename><replaceable><kernel-version></replaceable></filename>
corresponds to the kernel version specified in the boot loader's settings).
+ </para>
+ <para>
+ The bootloader is also used to pass arguments to the kernel it loads. This allows
the system to operate with a specified root filesystem, enable or disable kernel modules
and system features, or configure booting to a specific runlevel. For instructions on
using the boot loader to supply command line arguments to the kernel, refer to <xref
linkend="ch-grub" />. Specific kernel parameters are described in
<filename>/usr/share/doc/kernel-doc-*/Documentation/kernel-parameters.txt</filename>,
which is provided by the <package>kernel-doc</package> package. For
information on changing the runlevel at the boot loader prompt, refer <xref
linkend="s1-grub-runlevels" />.
+ </para>
+ <para>
+ The boot loader then places one or more appropriate
<filename>initramfs</filename> images into memory. The
<filename>initramfs</filename> is used by the kernel to load drivers and
modules necessary to boot the system.
+ </para>
+ <para>
+ Once the kernel and the <filename>initramfs</filename> image(s) are
loaded into memory, the boot loader hands control of the boot process to
<application>systemd</application>.
+ </para>
+ <para>
+ For a more detailed overview of the GRUB boot loader, refer to <xref
linkend="ch-grub" />.
+ </para>
</section>
-
- <section id="s2-boot-init-shutdown-kernel">
- <title>The Kernel</title>
- <indexterm significance="normal">
- <primary>boot process</primary>
- <secondary>stages of</secondary>
- <tertiary>kernel</tertiary>
-
- </indexterm>
- <indexterm significance="normal">
- <primary>kernel</primary>
- <secondary>role in boot process</secondary>
-
- </indexterm>
- <para>
- When the kernel is loaded, it immediately initializes and configures the
computer's memory and configures the various hardware attached to the system,
including all processors, I/O subsystems, and storage devices. It then looks for the
compressed <filename>initramfs</filename> image(s) in a predetermined location
in memory, decompresses it directly to <filename>/sysroot/</filename> via
<command>cpio</command>, and loads all necessary drivers. Next, it initializes
virtual devices related to the file system, such as LVM or software RAID, before
completing the <filename>initramfs</filename> processes and freeing up all the
memory the disk image once occupied.
- </para>
- <para>
- The kernel then creates a root device, mounts the root partition read-only, and frees
any unused memory.
- </para>
- <para>
- At this point, the kernel is loaded into memory and operational. However, since there
are no user applications that allow meaningful input to the system, not much can be done
with the system.
- </para>
- <para>
- To set up the user environment, the kernel executes the
<command>/sbin/init</command> program.
- </para>
-
+ <section id="s3-boot-init-shutdown-other-architectures">
+ <title>Boot Loaders for Other Architectures</title>
+ <para>
+ Once the kernel loads and the boot process continues, the process of bringing up
the system is the same. The main difference between each architecture's boot process
is in the application used to find and load the kernel.
+ </para>
+ <para>
+ For example, the IBM eServer pSeries architecture uses
<application>yaboot</application>, and the IBM System z systems use
the z/IPL boot loader. Configuration of alternative bootloaders is outside the scope of
this document.
+ </para>
</section>
-
- <section id="s2-boot-init-shutdown-init">
- <title>The <command>/sbin/init</command> Program</title>
- <indexterm significance="normal">
- <primary><command>init</command> command</primary>
- <secondary>role in boot process</secondary>
- <seealso>boot process</seealso>
-
- </indexterm>
- <indexterm significance="normal">
- <primary><command>init</command> command</primary>
- <seealso>boot process</seealso>
-
- </indexterm>
- <indexterm significance="normal">
- <primary>boot process</primary>
- <secondary>stages of</secondary>
- <tertiary><command>/sbin/init</command> command</tertiary>
-
- </indexterm>
- <para>
- The <command>/sbin/init</command> program (also called
<command>init</command>) coordinates the rest of the boot process and
configures the environment for the user.
- </para>
- <para>
- When the <command>init</command> command starts, it becomes the parent or
grandparent of all of the processes that start up automatically on the system. First, it
runs the <filename>/etc/rc.d/rc.sysinit</filename> script, which sets the
environment path, starts swap, checks the file systems, and executes all other steps
required for system initialization. For example, most systems use a clock, so
<filename>rc.sysinit</filename> reads the
<filename>/etc/sysconfig/clock</filename> configuration file to initialize the
hardware clock. Another example is if there are special serial port processes which must
be initialized, <filename>rc.sysinit</filename> executes the
<filename>/etc/rc.serial</filename> file.
- </para>
- <para>
- The <command>init</command> command then processes the jobs in the
<filename>/etc/event.d</filename> directory, which describe how the system
should be set up in each <firstterm>SysV init runlevel</firstterm>. Runlevels
are a state, or <firstterm>mode</firstterm>, defined by the services listed in
the SysV
<filename>/etc/rc.d/rc<replaceable><x></replaceable>.d/</filename>
directory, where <replaceable><x></replaceable> is the number of
the runlevel. For more information on SysV init runlevels, refer to <xref
linkend="s1-boot-init-shutdown-sysv" />.
- </para>
- <para>
- Next, the <command>init</command> command sets the source function
library, <filename>/etc/rc.d/init.d/functions</filename>, for the system,
which configures how to start, kill, and determine the PID of a program.
- </para>
- <para>
- The <command>init</command> program starts all of the background
processes by looking in the appropriate <filename>rc</filename> directory for
the runlevel specified as the default in <filename>/etc/inittab</filename>.
The <filename>rc</filename> directories are numbered to correspond to the
runlevel they represent. For instance, <filename>/etc/rc.d/rc5.d/</filename>
is the directory for runlevel 5.
- </para>
- <para>
- When booting to runlevel 5, the <command>init</command> program looks in
the <filename>/etc/rc.d/rc5.d/</filename> directory to determine which
processes to start and stop.
- </para>
- <para>
- Below is an example listing of the <filename>/etc/rc.d/rc5.d/</filename>
directory:
- </para>
+ </section>
+ <section id="s2-boot-init-shutdown-kernel">
+ <title>The Kernel</title>
+ <indexterm significance="normal">
+ <primary>boot process</primary>
+ <secondary>stages of</secondary>
+ <tertiary>kernel</tertiary>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>kernel</primary>
+ <secondary>role in boot process</secondary>
+ </indexterm>
+ <para>
+ When the kernel is loaded, it immediately initializes and configures the
computer's memory and configures the various hardware attached to the system,
including all processors, I/O subsystems, and storage devices. It then loads the
<filename>initramfs</filename> image(s) from disk and decompresses it into a
<systemitem>tmpfs</systemitem> as the acting root filesystem. The
<filename>initramfs</filename> contains programs and kernel modules required
to continue booting the system, such as those used to initialize virtual devices related
to file systems, like LVM or software RAID.
+ </para>
+ <para>The kernel uses the <filename>initramfs</filename> to continue
the boot process, and when the final root device is available, the
<filename>initramfs</filename> is unmounted and the real root filesystem is
mounted in it's place.
+ </para>
+ <para>
+ At this point, the kernel is loaded into memory and operational. However, since there
are no user applications that allow meaningful input to the system, not much can be done
with the system.
+ </para>
+ <para>
+ To set up the user environment, the kernel executes the system daemon,
<application>systemd</application>.
+ </para>
+ </section>
+ <section id="s2-boot-init-shutdown-systemd">
+ <title>Booting with <application>systemd</application></title>
+ <indexterm significance="preferred">
+ <primary><application>systemd</application></primary>
+ <secondary>role in boot process</secondary>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>boot process</primary>
+ <secondary>stages of</secondary>
+ </indexterm>
+ <para>
+ <application>systemd</application> is the first process started by the
kernel. It replaces the venerable <application>SysVinit</application> program
(also called <application>init</application>) and the newer
<application>Upstart</application> init system.
<application>systemd</application> coordinates the rest of the boot process
and configures the environment for the user.
+ </para>
+ <para>
+ <application>systemd</application> improves on other init systems with
increased parallelization . It starts the process of loading all programs it launches
immediately, and manages information between interdependent programs as they load. By
dissociating programs and their means of communication, each program is able to load
without waiting for unrelated or even dependent programs to load first.
+ </para>
-<screen>
-K05innd -> ../init.d/innd
-K05saslauthd -> ../init.d/saslauthd
-K10dc_server -> ../init.d/dc_server
-K10psacct -> ../init.d/psacct
-K10radiusd -> ../init.d/radiusd
-K12dc_client -> ../init.d/dc_client
-K12FreeWnn -> ../init.d/FreeWnn
-K12mailman -> ../init.d/mailman
-K12mysqld -> ../init.d/mysqld
-K15httpd -> ../init.d/httpd
-K20netdump-server -> ../init.d/netdump-server
-K20rstatd -> ../init.d/rstatd
-K20rusersd -> ../init.d/rusersd
-K20rwhod -> ../init.d/rwhod
-K24irda -> ../init.d/irda
-K25squid -> ../init.d/squid
-K28amd -> ../init.d/amd
-K30spamassassin -> ../init.d/spamassassin
-K34dhcrelay -> ../init.d/dhcrelay
-K34yppasswdd -> ../init.d/yppasswdd
-K35dhcpd -> ../init.d/dhcpd
-K35smb -> ../init.d/smb
-K35vncserver -> ../init.d/vncserver
-K36lisa -> ../init.d/lisa
-K45arpwatch -> ../init.d/arpwatch
-K45named -> ../init.d/named
-K46radvd -> ../init.d/radvd
-K50netdump -> ../init.d/netdump
-K50snmpd -> ../init.d/snmpd
-K50snmptrapd -> ../init.d/snmptrapd
-K50tux -> ../init.d/tux
-K50vsftpd -> ../init.d/vsftpd
-K54dovecot -> ../init.d/dovecot
-K61ldap -> ../init.d/ldap
-K65kadmin -> ../init.d/kadmin
-K65kprop -> ../init.d/kprop
-K65krb524 -> ../init.d/krb524
-K65krb5kdc -> ../init.d/krb5kdc
-K70aep1000 -> ../init.d/aep1000
-K70bcm5820 -> ../init.d/bcm5820
-K74ypserv -> ../init.d/ypserv
-K74ypxfrd -> ../init.d/ypxfrd
-K85mdmpd -> ../init.d/mdmpd
-K89netplugd -> ../init.d/netplugd
-K99microcode_ctl -> ../init.d/microcode_ctl
-S04readahead_early -> ../init.d/readahead_early
-S05kudzu -> ../init.d/kudzu
-S06cpuspeed -> ../init.d/cpuspeed
-S08ip6tables -> ../init.d/ip6tables
-S08iptables -> ../init.d/iptables
-S09isdn -> ../init.d/isdn
-S10network -> ../init.d/network
-S12syslog -> ../init.d/syslog
-S13irqbalance -> ../init.d/irqbalance
-S13portmap -> ../init.d/portmap
-S15mdmonitor -> ../init.d/mdmonitor
-S15zebra -> ../init.d/zebra
-S16bgpd -> ../init.d/bgpd
-S16ospf6d -> ../init.d/ospf6d
-S16ospfd -> ../init.d/ospfd
-S16ripd -> ../init.d/ripd
-S16ripngd -> ../init.d/ripngd
-S20random -> ../init.d/random
-S24pcmcia -> ../init.d/pcmcia
-S25netfs -> ../init.d/netfs
-S26apmd -> ../init.d/apmd
-S27ypbind -> ../init.d/ypbind
-S28autofs -> ../init.d/autofs
-S40smartd -> ../init.d/smartd
-S44acpid -> ../init.d/acpid
-S54hpoj -> ../init.d/hpoj
-S55cups -> ../init.d/cups
-S55sshd -> ../init.d/sshd
-S56rawdevices -> ../init.d/rawdevices
-S56xinetd -> ../init.d/xinetd
-S58ntpd -> ../init.d/ntpd
-S75postgresql -> ../init.d/postgresql
-S80sendmail -> ../init.d/sendmail
-S85gpm -> ../init.d/gpm
-S87iiim -> ../init.d/iiim
-S90canna -> ../init.d/canna
-S90crond -> ../init.d/crond
-S90xfs -> ../init.d/xfs
-S95atd -> ../init.d/atd
-S96readahead -> ../init.d/readahead
-S97messagebus -> ../init.d/messagebus
-S97rhnsd -> ../init.d/rhnsd
-S99local -> ../rc.local
-</screen>
- <para>
- As illustrated in this listing, none of the scripts that actually start and stop the
services are located in the <filename>/etc/rc.d/rc5.d/</filename> directory.
Rather, all of the files in <filename>/etc/rc.d/rc5.d/</filename> are
<firstterm>symbolic links</firstterm> pointing to scripts located in the
<filename>/etc/rc.d/init.d/</filename> directory. Symbolic links are used in
each of the <filename>rc</filename> directories so that the runlevels can be
reconfigured by creating, modifying, and deleting the symbolic links without affecting the
actual scripts they reference.
- </para>
- <para>
- The name of each symbolic link begins with either a
<computeroutput>K</computeroutput> or an
<computeroutput>S</computeroutput>. The
<computeroutput>K</computeroutput> links are processes that are killed on that
runlevel, while those beginning with an <computeroutput>S</computeroutput> are
started.
- </para>
- <para>
- The <command>init</command> command first stops all of the
<computeroutput>K</computeroutput> symbolic links in the directory by issuing
the
<command>/etc/rc.d/init.d/<replaceable><command></replaceable>
stop</command> command, where
<replaceable><command></replaceable> is the process to be
killed. It then starts all of the <computeroutput>S</computeroutput> symbolic
links by issuing
<command>/etc/rc.d/init.d/<replaceable><command></replaceable>
start</command>.
- </para>
- <note>
- <title>Note</title>
- <para>
- After the system is finished booting, it is possible to log in as root and execute
these same scripts to start and stop services. For instance, the command
<command>/etc/rc.d/init.d/httpd stop</command> stops the Apache HTTP Server.
- </para>
-
- </note>
- <para>
- Each of the symbolic links are numbered to dictate start order. The order in which
the services are started or stopped can be altered by changing this number. The lower the
number, the earlier it is started. Symbolic links with the same number are started
alphabetically.
- </para>
- <note>
- <title>Note</title>
- <para>
- One of the last things the <command>init</command> program executes is
the <filename>/etc/rc.d/rc.local</filename> file. This file is useful for
system customization. Refer to <xref linkend="s1-boot-init-shutdown-run-boot"
/> for more information about using the <filename>rc.local</filename>
file.
- </para>
-
- </note>
- <para>
+ <itemizedlist>
+ <title> The Boot Process </title>
+ <listitem><para>
+ A socket is created for each daemon that will be launched. The sockets allow daemons
to communicate with each other and userspace programs. Because the sockets are abstracted
from the processes that use them, interdependent services do not have to wait for each
other to come up before sending messages to the socket.
+ </para></listitem>
+ <listitem><para>
+ New process are started by <application>systemd</application>.The
processes are assigned to <function>Control Groups</function>, or
<function> cgroups</function>. Processes in a
<function>cgroup</function> are isolated to resources alloted by the kernel,
and the restrictions are inherited by newly spawned processes. Communication with outside
processes will be handled by the kernel through sockets.
+ </para></listitem>
+ <listitem><para>
+ As they load, processes connect to their sockets to receive any waiting messages
and communicate with other sockets. <application>systemd</application> handles
dependencies between programs, but does not need a preconfigured boot order. Userspace
tools are loaded as the devices and services they depend on become available.
+ </para></listitem>
+ <listitem><para>
+ The user is presented with a login screen for the freshly booted Linux system.
+ </para></listitem>
+ </itemizedlist>
+ <note>
+ <title>Control Groups</title>
+ <para>
+
+ </para>
+ </note>
+ </section>
+
+ <section id="s1-boot-init-shutdown-targets">
+ <title>systemd targets</title>
+ <indexterm significance="normal">
+ <primary>systemd</primary>
+ <secondary><function>targets</function></secondary>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>runlevels</primary>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>cgroups</primary>
+ <secondary>use by
<application>systemd</application></secondary>
+ </indexterm>
+ <para>
+ <application>systemd</application> replaces traditional
<application>SysVinit</application> <function>runlevels</function>
with predefined groups of <function>units</function> called
<function>targets</function>. <function>Targets</function> are
usually defined according to the intended use of the system, and ensure that required
dependencies for that use are met.
+ </para>
+ <para>
+ The system boots to the target described in
<filename>/lib/systemd/system/default.target</filename>. This file is a
symlink that can be changed when booting to a different target is desired. Appending
<command>systemd.unit=<replaceable>custom</replaceable>.target</command>
to the kernel's boot arguments will override the default target.
+ </para>
+ <para>
+ The following table shows some standard preconfigured targets, the
<application>sysVinit</application> <function>runlevels</function>
they resemble and the use case they address.
+ </para>
+ <table>
+ <title>Predefined <application>systemd</application>
targets</title>
+ <tgroup cols="3" align="left" colsep="1"
rowsep="1">
+ <colspec colname="runlevel" colnum="1" />
+ <colspec colname="target" colnum="2" />
+ <colspec colname="usage" colnum="3" />
+ <thead>
+ <row>
+ <entry>Runlevel</entry>
+ <entry>Target</entry>
+ <entry>Usage</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>1,single</entry>
+ <entry>rescue.target</entry>
+ <entry>single user mode, for recovery of critical system components or
configuration</entry>
+ </row>
+ <row>
+ <entry>3</entry>
+ <entry>multi-user.target</entry>
+ <entry>Non-graphical multi-user console access, via local TTYs
or network.</entry>
+ </row>
+ <row>
+ <entry>5</entry>
+ <entry>graphical.target</entry>
+ <entry>A GUI session. Typically provides the user with a fully
featured desktop environment.</entry>
+ </row>
+ <row>
+ <entry>4</entry>
+
<entry><replaceable>custom</replaceable>.target</entry>
+ <entry><application>systemd</application> allows any
number of custom defined targets.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </section>
+
+ <section id="s2-boot-init-shutdown-systemd-units">
+ <title><application>systemd</application>
<function>units</function></title>
+ <indexterm significance="normal">
+ <primary><application>systemd</application></primary>
+ <secondary>units</secondary>
+ </indexterm>
+ <para>
+ Functions administered by <application>systemd</application> are
referred to as <function>units</function>. Each
<function>unit</function> has a name and a type, and is decribed in a file
that follows the convention of
<replaceable>unit-name</replaceable>.<replaceable>type</replaceable>.
The configuration file defines the relationship between a
<function>unit</function> and it's dependencies.
+Let's look at the different types of units:
+ </para>
+
+ <segmentedlist>
+ <segtitle><function>unit</function> type</segtitle>
+ <segtitle>Role</segtitle>
+ <seglistitem>
+ <seg><function>socket</function></seg>
+ <seg>
+ These provide an endpoint for interprocesses communication. Messages can be
transported through files, or network or unix sockets. Each
<function>socket</function> has a corresponding
<function>service</function>.
+ </seg>
+ </seglistitem>
+
+ <seglistitem>
+ <seg><function>service</function></seg>
+ <seg>
+ These are traditional daemons. <function>Service</function>
<function>units</function> are described in simple configuration files that
define the type, execution, and envoronment of the program, as well as information
regarding how <application>systemd</application> should monitor it.
+ </seg>
+ </seglistitem>
+
+ <seglistitem>
+ <seg><function>device</function></seg>
+ <seg>
+ These are automatically created for all devices discovered by the kernel. These
<function>units</function> are provided for services that are dependent on
devices, or for virtual devices that are dependent on services, as with a network block
device.
+ </seg>
+ </seglistitem>
+
+ <seglistitem>
+ <seg><function>mount</function></seg>
+ <seg>
+ These <function>units</function> allow
<application>systemd</application>to monitor the mounting and unmounting of
filesystems, and allow <function>units</function> to declare relationships
with the filesystems they use.
+ </seg>
+ </seglistitem>
+
+ <seglistitem>
+ <seg><function>automount</function></seg>
+ <seg>
+ These <function>units</function> facilitate dynamic mounting of
filesystems when their mountpoint is accessed. They are always paired with a
<function>mount</function> <function>unit</function>.
+ </seg>
+ </seglistitem>
+
+ <seglistitem>
+ <seg><function>target</function></seg>
+ <seg>
+ These are logical groupings of <function>units</function> that are
required for userspace functionality. Some are large, such as
<filename>multi-user.target</filename> that defines a full graphical user
environment, or more topical, such as <filename>bluetooth.target</filename>
that provides the services a user expects to be available when using bluetooth devices.
+ </seg>
+ </seglistitem>
+
+ <seglistitem>
+ <seg><function>snapshot</function></seg>
+ <seg><function>snapshots</function> allow the user to save the
state of all <function>units</function> with the command
<command>systemctl snapshot</command> and return to that state with
<command>systemctl isolate</command>. This is useful for temporary adjustments
that don't merit reconfiguration of a target.
+ </seg>
+ </seglistitem>
+ </segmentedlist>
+
+
+ <para>
+ Although <application>systemd</application>
<function>units</function> will ultimately be available for all services, it
retains support for legacy init scripts. <function>units</function> are
dynamically created for services without native configurations, with dependencies inferred
from LSB headers in the script. There are drawbacks to this method, so it is best to have
a native <application>systemd</application>
<function>unit</function> file.
+ </para>
+ <para>
+ The function and usage of legacy init systems and their configuration files is
outside of the scope of this document.
+ </para>
+
+ <!-- section covering symlinks for targets. -->
+ <!--note about managing services-->
+ <!--paragraphs describing various runlevels:
+ <para>
After the <command>init</command> command has progressed through the
appropriate <filename>rc</filename> directory for the runlevel,
<application>Upstart</application> forks an
<command>/sbin/mingetty</command> process for each virtual console (login
prompt) allocated to the runlevel by the job definition in the
<filename>/etc/event.d</filename> directory. Runlevels 2 through 5 have all
six virtual consoles, while runlevel 1 (single user mode) has one, and runlevels 0 and 6
have none. The <command>/sbin/mingetty</command> process opens communication
pathways to <firstterm>tty</firstterm> devices<footnote> <para>
Refer to the Fedora Deployment Guide for more information about
<filename>tty</filename> devices.
</para>
</footnote>, sets their modes, prints the login prompt, accepts the user's
username and password, and initiates the login process.
</para>
+
<para>
In runlevel 5, <application>Upstart</application> runs a script called
<filename>/etc/X11/prefdm</filename>. The
<filename>prefdm</filename> script executes the preferred X display
manager<footnote> <para>
Refer to the Fedora Deployment Guide for more information about display managers.
@@ -428,42 +443,8 @@ S99local -> ../rc.local
</para>
<para>
Once finished, the system operates on runlevel 5 and displays a login screen.
- </para>
-
- </section>
-
- <section id="s2-boot-init-shutdown-jobs">
- <title>Job definitions</title>
- <para>
- Previously, the <package>sysvinit</package> package provided the
<application>init</application> daemon for the default configuration. When the
system started, this <application>init</application> daemon ran the
<filename>/etc/inittab</filename> script to start system processes defined for
each runlevel. The default configuration now uses an event-driven
<application>init</application> daemon provided by the
<package>Upstart</package> package. Whenever particular
<firstterm>events</firstterm> occur, the
<application>init</application> daemon processes
<firstterm>jobs</firstterm> stored in the
<filename>/etc/event.d</filename> directory. The
<application>init</application> daemon recognizes the start of the system as
such an event.
- </para>
- <para>
- Each job typically specifies a program, and the events that trigger
<application>init</application> to run or to stop the program. Some jobs are
constructed as <firstterm>tasks</firstterm>, which perform actions and then
terminate until another event triggers the job again. Other jobs are constructed as
<firstterm>services</firstterm>, which
<application>init</application> keeps running until another event (or the
user) stops it.
- </para>
- <para>
- For example, the <filename>/etc/events.d/tty2</filename> job is a service
to maintain a virtual terminal on <application>tty2</application> from the
time that the system starts until the system shuts down, or another event (such as a
change in runlevel) stops the job. The job is constructed so that
<application>init</application> will restart the virtual terminal if it stops
unexpectedly during that time:
- </para>
-
-<screen># tty2 - getty
-#
-# This service maintains a getty on tty2 from the point the system is
-# started until it is shut down again.
-
-start on stopped rc2
-start on stopped rc3
-start on stopped rc4
-start on started prefdm
-
-stop on runlevel 0
-stop on runlevel 1
-stop on runlevel 6
-
-respawn
-exec /sbin/mingetty tty2
-</screen>
-
- </section>
-
+ </para>-->
+<!--watchdogs!-->
</section>
@@ -494,262 +475,442 @@ exec /sbin/mingetty tty2
<see><command>setserial</command> command</see>
</indexterm>
- <para>
- The <filename>/etc/rc.d/rc.local</filename> script is executed by the
<command>init</command> command at boot time or when changing runlevels.
Adding commands to the bottom of this script is an easy way to perform necessary tasks
like starting special services or initialize devices without writing complex
initialization scripts in the <filename>/etc/rc.d/init.d/</filename> directory
and creating symbolic links.
- </para>
- <para>
- The <filename>/etc/rc.serial</filename> script is used if serial ports
must be setup at boot time. This script runs <command>setserial</command>
commands to configure the system's serial ports. Refer to the
<command>setserial</command> man page for more information.
- </para>
- </section>
-
- <section id="s1-boot-init-shutdown-sysv">
- <title>SysV Init Runlevels</title>
- <indexterm significance="normal">
- <primary>SysV init</primary>
- <see><command>init</command> command</see>
+ <para>
+ Historically, those wishing to execute additional programs at boot could insert
commands into <filename>/etc/rc.local</filename>. While
<application>systemd</application> will use this file, writing
<function>unit</function> files can be simple, effective, and much more
flexible. Consider this example <function>unit</function> file:
+ </para>
+ <example>
+ <title>An example of a simple unit file</title>
+ <programlisting>
+#cat /lib/systemd/system/example.service
+[Unit]
+Description=A service that executes a user script on startup
+Wants=network.target
- </indexterm>
- <indexterm significance="normal">
- <primary><command>init</command> command</primary>
- <secondary>runlevels</secondary>
- <tertiary>directories for</tertiary>
- </indexterm>
- <indexterm significance="normal">
- <primary><command>init</command> command</primary>
- <secondary>SysV init</secondary>
- <tertiary>definition of</tertiary>
+[Service]
+ExecStart=/opt/domain/bin/example
+Type=oneshot
- </indexterm>
- <indexterm significance="normal">
- <primary><command>init</command> command</primary>
- <secondary>configuration files</secondary>
- <tertiary><filename>/etc/inittab</filename> </tertiary>
+[Install]
+WantedBy=multi-user.target
+Alias=illustration.service
- </indexterm>
- <para>
- The SysV init runlevel system provides a standard process for controlling which
programs <command>init</command> launches or halts when initializing a
runlevel. SysV init was chosen because it is easier to use and more flexible than the
traditional BSD-style init process.
+ </programlisting>
+ </example>
+
+ <para>
+ The <function>[Unit]</function> section has a shord description, and
dependencies on other targets. The various types of dependencies and attributes used in
this section are described in <command>man systemd.unit</command>
</para>
- <para>
- The configuration files for SysV init are located in the
<filename>/etc/rc.d/</filename> directory. Within this directory, are the
<filename>rc</filename>, <filename>rc.local</filename>,
<filename>rc.sysinit</filename>, and, optionally, the
<filename>rc.serial</filename> scripts as well as the following directories:
+ <para>
+ The <function>[Service]</function> section establishes the actual command
to be executed, and describes how <application>systemd</application> should
handle the process. Options for this section are described in <command>man
systemd.service</command>.
</para>
-
-<screen>
-<computeroutput>init.d/ rc0.d/ rc1.d/ rc2.d/ rc3.d/ rc4.d/ rc5.d/
rc6.d/</computeroutput></screen>
- <para>
- The <filename>init.d/</filename> directory contains the scripts used by
the <command>/sbin/init</command> command when controlling services. Each of
the numbered directories represent the six runlevels configured by default under Fedora.
+ <para>
+ The <function>[Install]</function> sets relationships with
<function>targets</function> and similar behaviors. Options for this section
are are also described in <command>man systemd.unit</command>
</para>
- <section id="s2-init-boot-shutdown-rl">
- <title>Runlevels</title>
- <indexterm significance="normal">
- <primary>runlevels</primary>
- <see><command>init</command> command</see>
-
- </indexterm>
- <indexterm significance="normal">
- <primary><command>init</command> command</primary>
- <secondary>runlevels accessed by</secondary>
-
- </indexterm>
- <para>
- The idea behind SysV init runlevels revolves around the idea that different systems
can be used in different ways. For example, a server runs more efficiently without the
drag on system resources created by the X Window System. Or there may be times when a
system administrator may need to operate the system at a lower runlevel to perform
diagnostic tasks, like fixing disk corruption in runlevel 1.
- </para>
- <para>
- The characteristics of a given runlevel determine which services are halted and
started by <command>init</command>. For instance, runlevel 1 (single user
mode) halts any network services, while runlevel 3 starts these services. By assigning
specific services to be halted or started on a given runlevel,
<command>init</command> can quickly change the mode of the machine without the
user manually stopping and starting services.
- </para>
- <para>
- The following runlevels are defined by default under Fedora:
- </para>
- <blockquote>
- <itemizedlist>
- <listitem>
- <para>
- <command>0</command> — Halt
- </para>
-
- </listitem>
- <listitem>
- <para>
- <command>1</command> — Single-user text mode
- </para>
-
- </listitem>
- <listitem>
- <para>
- <command>2</command> — Not used (user-definable)
- </para>
-
- </listitem>
- <listitem>
- <para>
- <command>3</command> — Full multi-user text mode
- </para>
-
- </listitem>
- <listitem>
- <para>
- <command>4</command> — Not used (user-definable)
- </para>
-
- </listitem>
- <listitem>
- <para>
- <command>5</command> — Full multi-user graphical mode (with
an X-based login screen)
- </para>
-
- </listitem>
- <listitem>
- <para>
- <command>6</command> — Reboot
- </para>
-
- </listitem>
-
- </itemizedlist>
-
- </blockquote>
- <para>
- In general, users operate Fedora at runlevel 3 or runlevel 5 — both full
multi-user modes. Users sometimes customize runlevels 2 and 4 to meet specific needs,
since they are not used.
- </para>
- <para>
- The default runlevel for the system is listed in
<filename>/etc/inittab</filename>. To find out the default runlevel for a
system, look for the line similar to the following near the bottom of
<filename>/etc/inittab</filename>:
- </para>
-
-<screen>
-<computeroutput>id:5:initdefault:</computeroutput></screen>
- <para>
- The default runlevel listed in this example is five, as the number after the first
colon indicates. To change it, edit <filename>/etc/inittab</filename> as
root.
- </para>
- <warning>
- <title>Warning</title>
- <para>
- Be very careful when editing <filename>/etc/inittab</filename>. Simple
typos can cause the system to become unbootable. If this happens, either use a boot
diskette, enter single-user mode, or enter rescue mode to boot the computer and repair the
file.
- </para>
- <para>
- For more information on single-user and rescue mode, refer to the chapter titled
<citetitle>Basic System Recovery</citetitle> in the <citetitle>Fedora
Deployment Guide</citetitle>.
- </para>
-
- </warning>
- <para>
- It is possible to change the default runlevel at boot time by modifying the arguments
passed by the boot loader to the kernel. For information on changing the runlevel at boot
time, refer to <xref linkend="s1-grub-runlevels" />.
- </para>
-
- </section>
- <section id="s2-boot-init-shutdown-sysv-util">
- <title>Runlevel Utilities</title>
- <indexterm significance="normal">
- <primary>runlevels</primary>
- <secondary>configuration of</secondary>
- <seealso>services</seealso>
-
- </indexterm>
- <indexterm significance="normal">
- <primary><application>Services Configuration Tool</application>
</primary>
- <seealso>services</seealso>
-
- </indexterm>
- <indexterm significance="normal">
- <primary>services</primary>
- <secondary>configuring with <application>Services Configuration
Tool</application> </secondary>
-
- </indexterm>
- <indexterm significance="normal">
- <primary><application>ntsysv</application> </primary>
- <seealso>services</seealso>
-
- </indexterm>
- <indexterm significance="normal">
- <primary>services</primary>
- <secondary>configuring with <application>ntsysv</application>
</secondary>
-
- </indexterm>
- <indexterm significance="normal">
- <primary>services</primary>
- <secondary>configuring with <command>chkconfig</command>
</secondary>
-
- </indexterm>
- <indexterm significance="normal">
- <primary><command>chkconfig</command> </primary>
- <seealso>services</seealso>
-
- </indexterm>
- <para>
- One of the best ways to configure runlevels is to use an <firstterm>initscript
utility</firstterm>. These tools are designed to simplify the task of maintaining
files in the SysV init directory hierarchy and relieves system administrators from having
to directly manipulate the numerous symbolic links in the subdirectories of
<filename>/etc/rc.d/</filename>.
- </para>
- <para>
- Fedora provides three such utilities:
- </para>
- <itemizedlist>
- <listitem>
- <para>
- <command>/sbin/chkconfig</command> — The
<command>/sbin/chkconfig</command> utility is a simple command line tool for
maintaining the <filename>/etc/rc.d/init.d/</filename> directory hierarchy.
- </para>
-
- </listitem>
- <listitem>
- <para>
- <application>/usr/sbin/ntsysv</application> — The
ncurses-based <application>/sbin/ntsysv</application> utility provides an
interactive text-based interface, which some find easier to use than
<command>chkconfig</command>.
- </para>
-
- </listitem>
- <listitem>
- <para>
- <application>Services Configuration Tool</application> — The
graphical <application>Services Configuration Tool</application>
(<command>system-config-services</command>) program is a flexible utility for
configuring runlevels.
- </para>
-
- </listitem>
-
- </itemizedlist>
- <para>
- Refer to the chapter titled <citetitle>Controlling Access to
Services</citetitle> in the <citetitle>Fedora Deployment
Guide</citetitle> for more information regarding these tools.
- </para>
-
- </section>
-
- </section>
+ </section>
- <section id="s1-boot-init-shutdown-shutdown">
- <title>Shutting Down</title>
- <indexterm significance="normal">
- <primary>shutdown</primary>
- <seealso>halt</seealso>
-
- </indexterm>
- <indexterm significance="normal">
- <primary>halt</primary>
- <seealso>shutdown</seealso>
-
- </indexterm>
- <para>
- To shut down Fedora, the root user may issue the
<command>/sbin/shutdown</command> command. The
<command>shutdown</command> man page has a complete list of options, but the
two most common uses are:
- </para>
-
-<screen>
-<command>/sbin/shutdown -h now</command></screen>
- <para>
- and
- </para>
-
-<screen>
-<command>/sbin/shutdown -r now</command></screen>
- <para>
- After shutting everything down, the <command>-h</command> option halts the
machine, and the <command>-r</command> option reboots.
- </para>
- <para>
- PAM console users can use the <command>reboot</command> and
<command>halt</command> commands to shut down the system while in runlevels 1
through 5. For more information about PAM console users, refer to the Fedora Deployment
Guide.
- </para>
- <para>
- If the computer does not power itself down, be careful not to turn off the computer
until a message appears indicating that the system is halted.
+ <section id="s1-boot-init-shutdown-administration">
+ <title>Administering services with
<application>systemd</application></title>
+ <indexterm significance="normal">
+ <primary>systemd</primary>
+ <secondary>administration utilites</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>systemctl</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>chkconfig</primary>
+ <see>systemctl</see>
+ </indexterm>
+
+ <indexterm>
+ <primary><command>service</command> command</primary>
+ <see>systemctl</see>
+ </indexterm>
+
+
+
+ <para>
+ The move to <application>systemd</application> also brought new
administration utilities to Fedora. Administrators have the ability to start, stop, and
restart services as with <application>sysVinit</application>, but also have
access to much more information and functionality.
+ </para>
+ <warning>
+ <title>Expect legacy commands to be depricated!</title>
+ <para>
+ <command>systemctl</command> fully replaces traditional utilites like
<command>service</command> and <command>chkconfig</command>. While
some services can still be administered with these legacy commands,
<emphasis>all</emphasis> services can be administered with
<command>systemctl</command>.
</para>
- <para>
- Failure to wait for this message can mean that not all the hard drive partitions are
unmounted, which can lead to file system corruption.
- </para>
-
- </section>
-
-
-</appendix>
-
+ </warning>
+
+ <para>
+ <command>/usr/bin/systemctl</command> does most of the heavy lifting when
starting and stopping services, or configuring them to run at boot. Let us look at what
systemctl can do:
+ </para>
+
+ <section id="s1-boot-init-shutdown-administration-status">
+ <title>Checking up on services</title>
+ <screen>
+
+<![CDATA[
+[root@fedora ~]# systemctl status sshd.service
+sshd.service - OpenSSH server daemon
+ Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
+ Active: inactive (dead) since Thu, 20 Sep 2012 22:56:55 -0600; 17s ago
+ Process: 971 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
+ Process: 941 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
+ CGroup: name=systemd:/system/sshd.service
+
+Sep 20 19:17:02 fqdn.fedora.lan sshd[23515]: pam_unix(sshd:auth): authentication ...3
+Sep 20 19:17:03 fqdn.fedora.lan sshd[23515]: Failed password for invalid user usr...2
+Sep 20 19:17:04 fqdn.fedora.lan sshd[23515]: Received disconnect from 192.168.1.....]
+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: Invalid user db2inst1 from 192.168.1...]
+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: input_userauth_request: invalid user...]
+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: pam_unix(sshd:auth): check pass; use...n
+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: pam_unix(sshd:auth): authentication ...3
+Sep 20 19:17:08 fqdn.fedora.lan sshd[23517]: Failed password for invalid user db2...2
+Sep 20 19:17:08 fqdn.fedora.lan sshd[23517]: Received disconnect from 192.168.1.....]
+Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
+]]>
+ </screen>
+ <para>
+ The command <command>systemctl status
<replaceable>sshd</replaceable>.service</command> can tell us much more
than if the service is running. In this example with
<application>sshd</application>, we can see that the service is
<function>enabled</function> but not <function>active</function>.
We know how the service was invoked, what the PID was, and when it was stopped. We can
also see the last portion of the service's log.
+ </para>
+ </section>
+ <section id="s1-boot-init-shutdown-administration-start">
+ <title>Starting and stopping services</title>
+ <screen><command>systemctl start
sshd.service</command></screen>
+ <screen><command>systemctl stop
sshd.service</command></screen>
+ <screen><command>systemctl restart
sshd.service</command></screen>
+
+ <para>
+ These commands will start, stop, and restart the service. The commands may
not report the success or failure of the intended action, so we can check the status of
the service with <command>systemctl status</command>.
<application>systemctl</application> might report helpful information about a
misbehaving application in the <function>status</function>, but the
application's own logs are more relevant.
+ </para>
+ </section>
+ <section id="s1-boot-init-shutdown-administration-enable">
+ <title>Running services automatically</title>
+ <screen><command>systemctl enable
sshd.service</command></screen>
+ <screen><command>systemctl disable
sshd.service</command></screen>
+ <para>
+ A service that is enabled will start automatically when the system boots.
A service that is disabled will not start at boot. These commands are manipulating
symbolic links in <filename>/lib/systemd/system/</filename> and
<filename>/lib/systemd/user/</filename> while retaining the relationships with
other units established in the <filename>.service</filename> file. While the
symlinks can be manipulated manually, <application>systemctl</application>
also rebuilds the <application>systemd</application> configuration, saving the
extra step of invoking <command>systemctl daemon-reload</command>.
+ </para>
+ </section>
+ <section id="s1-boot-init-shutdown-administration-kill">
+ <title>Killing and Masking services</title>
+ <screen><command>systemctl kill
sshd.service</command></screen>
+ <screen><command>systemctl kill -s USR1
<replaceable>daemon</replaceable>.service</command></screen>
+ <para>With the first command,
<application>systemd</application> kills all processes and child processes of
the <application>sshd</application> service. The second command demonstrates
how any Unix signal can be sent to the processes of a service.
+ </para>
+ <screen><command>systemctl mask
<replaceable>daemon</replaceable>.service</command></screen>
+ <para>
+ Masking a service prevents the service from being started manually or
automatically. For this example, <application>systemctl</application> is
creating a symlink from
<filename>/etc/systemd/system/daemon.service</filename> to /dev/null. Targets
in <filename>/etc/systemd</filename> override those provided by packages in
<filename>/lib/systemd</filename>.
<application>systemd</application> recognizes the symlink and will not start
the service.
+ </para>
+ </section>
+
+ <section id="s1-boot-init-shutdown-administration-systemctl">
+ <title>Getting more from
<application>systemd</application></title>
+<!--rewrite with the goal of still troubleshooting sshd?-->
+ <para>
+ <application>systemctl</application> works with not only services but all
other unit types, and is a valuable tool when monitoring or troubleshooting a system. It
can list all known units, limit the results to a single unit type, show only failed units,
or examine unit relationships. The table below shows some useful systemctl features and
should help system administrators replace their old workflow in
<application>sysVinit</application>.
+ </para>
+ <table>
+ <title><application>systemd</application> command
reference</title>
+ <tgroup cols='3'>
+ <colspec colname='sysv' />
+ <colspec colname='systemd' />
+ <colspec colname='notes' />
+ <thead>
+ <row>
+ <entry>
+ <application>sysVinit</application> command
+ </entry>
+ <entry>
+ <application>systemd</application> command
+ </entry>
+ <entry>
+ Notes
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ <command>
+ service sshd start
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl start sshd.service
+ </command>
+ </entry>
+ <entry>
+ Used to start a service (not reboot persistent)
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ service sshd stop
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl stop sshd.service
+ </command>
+ </entry>
+ <entry>
+ Used to stop a service. (not reboot persistent)
+ </entry>
+ </row>
+
+ <row>
+ <entry>
+ <command>
+ service sshd restart
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl restart sshd.service
+ </command>
+ </entry>
+ <entry>
+ Used to start and stop a service.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ service sshd reload
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl reload sshd.service
+ </command>
+ </entry>
+ <entry>
+ When supported, reloads the config file without interrupting
pending operations.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ service sshd condrestart
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl condrestart sshd.service
+ </command>
+ </entry>
+ <entry>
+ Restarts if the service is already running.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ service sshd status
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl status sshd.service
+ </command>
+ </entry>
+ <entry>
+ Tells whether a service is currently running.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ ls /etc/rc.d/init.d/
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl list-unit-files --type=service
+ </command>
+ </entry>
+ <entry>
+ Lists all available services.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ chkconfig sshd on
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl enable sshd.service
+ </command>
+ </entry>
+ <entry>
+ Always run the service at this target (runlevel.)
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ chkconfig sshd off
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl disable sshd.service
+ </command>
+ </entry>
+ <entry>
+ Do not automatically run the service at this target (runlevel.)
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ chkconfig --list
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl list-units -t service --all
+ </command>
+ </entry>
+ <entry>
+ Print a table of available services and their status.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ chkconfig sshd --list
+ </command>
+ </entry>
+ <entry>
+ <command>
+ ls /etc/systemd/system/*.wants/sshd.service
+ </command>
+ </entry>
+ <entry>
+ Lists the targets that will include the service.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ chkconfig sshd --add
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl daemon-reload
+ </command>
+ </entry>
+ <entry>
+ Used when you create a service file or modify any configuration.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ telinit 3
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl isolate multi-user.target
+ </command>
+ </entry>
+ <entry>
+ Move system into another target (change runlevels.)
+ </entry>
+ </row>
+<row>
+ <entry>
+ <command>
+ [no comparable command]
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl show -p "Wants" multi-user.target
+ </command>
+ </entry>
+ <entry>
+ Lists units pulled in by a given target.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ [no comparable command]
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl show -p "After" sshd.service
+ </command>
+ </entry>
+ <entry>
+ Shows dependent services and other targets.
+ </entry>
+ </row>
+
+ <row>
+ <entry>
+ <command>
+ [no comparable command]
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemd --test --system --unit=multi-user.target
+ </command>
+ </entry>
+ <entry>
+ Simulates booting the system to a given target
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ [no comparable command]
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemd-analyze plot > boot.svg
+ </command>
+ </entry>
+ <entry>
+ Generates a diagnostically useful graphical representation of the boot process.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ ps xawf -eo pid,user,cgroup,args
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemd-cgls
+ </command>
+ </entry>
+ <entry>
+ Display control group process tree.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </section>
+ </section>
+
+
+ </appendix>