[install-guide: 13/18] Added systemd target description, minor changes in other areas.
Pete Travis
immanetize at fedoraproject.org
Fri Oct 26 05:51:59 UTC 2012
commit dfec68d3b443c98e08dfde1119c52812f324694c
Author: Pete Travis <immanetize at fedoraproject.org>
Date: Mon Sep 17 00:18:24 2012 -0600
Added systemd target description, minor changes in other areas.
en-US/Boot_Init_Shutdown.xml | 535 +++++++++++++++++++++++-------------------
1 files changed, 292 insertions(+), 243 deletions(-)
---
diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
index 871657e..577b832 100644
--- a/en-US/Boot_Init_Shutdown.xml
+++ b/en-US/Boot_Init_Shutdown.xml
@@ -4,177 +4,177 @@
%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.
+ <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>
- <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:
+ <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 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>
-
- </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 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 suite 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>
- <indexterm>
- <primary>GUID Partition Table</primary>
- <see>GPT</see>
- </indexterm>
- <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>
- <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>
+ <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">
+ </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>
@@ -210,7 +210,7 @@
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. This is particularly important if SCSI hard drives are present or if the systems use the ext3 or ext4 file system.
+ 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 the kernel.
@@ -222,7 +222,7 @@
<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.
+ 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.
@@ -241,10 +241,9 @@
<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.
+ 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 then creates a root device, mounts the root partition read-only, and frees any unused memory.
+ <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.
@@ -269,36 +268,112 @@
<para>
<application>systemd</application> improves on other init systems by offering 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>
-
- <indexterm significance="normal">
- <primary>cgroups</primary>
- <secondary>use by <application>systemd</application></secondary>
- </indexterm>
-
+
<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 started by <application>systemd</application> 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.
+ New process are started by <application>systemd</application>.
+ </para></listitem>
+ <listitem><para>
+ As they load, processes connect to their sockets and wait. <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>
+ 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.
+ </note>
</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>
+ <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>
+
+ <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>
+ 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>
- <para>
+ <section id="s2-boot-init-shutdown-systemd-management">
+ <title>Runlevel Utilities</title>
+ <indexterm significance="normal">
+ <primary>runlevels</primary>
+ <secondary>configuration of</secondary>
+ <seealso>services</seealso>
+ </indexterm>
+ <para>
+ <application>systemd</application> is administered using a number of utilities.
+ </para>
+ </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>
+ </para>
<segmentedlist>
<segtitle><function>unit</function> type</segtitle>
@@ -362,8 +437,7 @@ Let's look at the different types of units:
<!-- section covering symlinks for targets. -->
<!--note about managing services-->
- <!--IMPORTANT: add a comment that rc.local still works!-->
- <!--paragraphs describing various runlevels:
+ <!--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.
@@ -411,69 +485,44 @@ Let's look at the different types of units:
<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>
+ 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
- </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><command>init</command> command</primary>
- <secondary>configuration files</secondary>
- <tertiary><filename>/etc/inittab</filename> </tertiary>
- </indexterm>
- <para>
-<!-- There's possibly too much in here for a table; present it another way? -->
- <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. 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="4" align="left" colsep="1" rowsep="1" />
- <colspec colname="runlevel" colnum="1" />
- <colspec colname="target" colnum="2" />
- <colspec colname="usage" colnum="3" />
- <colspec colname="member_units" colnum="4" />
- <thead>
- <row>
- <entry>Runlevel</entry>
- <entry>Target</entry>
- <entry>Usage</entry>
- <entry>Units</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>
- </tbody>
- </table>
- </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>
+[Service]
+ExecStart=/opt/domain/bin/example
+Type=oneshot
+
+[Install]
+WantedBy=multi-user.target
+Alias=illustration.service
- </section>
+ </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 <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>
+ <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>
+
+
<!-- basically, systemd to sysvinit cheatsheet here. systemctl enable, et al-->
<!-- </section>-->
More information about the docs-commits
mailing list