[install-guide: 17/18] correcting some typos and tags in init section
Pete Travis
immanetize at fedoraproject.org
Fri Oct 26 05:52:20 UTC 2012
commit d9d6360351150b593475731d735c3ce27b651c6e
Author: Pete Travis <immanetize at fedoraproject.org>
Date: Thu Oct 25 23:31:44 2012 -0600
correcting some typos and tags in init section
en-US/Boot_Init_Shutdown.xml | 208 +++++++++++++++++++-----------------------
1 files changed, 92 insertions(+), 116 deletions(-)
---
diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
index f86ce87..73b5cfc 100644
--- a/en-US/Boot_Init_Shutdown.xml
+++ b/en-US/Boot_Init_Shutdown.xml
@@ -177,28 +177,28 @@
<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>
+ <title>The GRUB2 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>
+ <primary>GRUB2</primary>
<secondary>role in boot process</secondary>
</indexterm>
<indexterm significance="normal">
- <primary>GRUB</primary>
+ <primary>GRUB2</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.
+ The system loads GRUB2 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> .
+ <application>GRUB2</application> 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.
+ GRUB2 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.
@@ -216,7 +216,7 @@
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" />.
+ For a more detailed overview of the GRUB2 boot loader, refer to <xref linkend="ch-grub" />.
</para>
</section>
<section id="s3-boot-init-shutdown-other-architectures">
@@ -243,7 +243,7 @@
<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>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 its 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.
@@ -266,7 +266,7 @@
<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.
+ <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>
<itemizedlist>
@@ -275,7 +275,7 @@
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.
+ New processes 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 allotted 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.
@@ -284,75 +284,7 @@
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>
<section id="s2-boot-init-shutdown-systemd-units">
<title><application>systemd</application> <function>units</function></title>
@@ -361,7 +293,7 @@
<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.
+ 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 described 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 its dependencies.
Let's look at the different types of units:
</para>
@@ -371,7 +303,7 @@ Let's look at the different types of units:
<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>.
+ These provide an endpoint for interprocess communication. Messages can be transported through files, or network or Unix sockets. Each <function>socket</function> has a corresponding <function>service</function>.
</seg>
</seglistitem>
@@ -406,7 +338,7 @@ Let's look at the different types of units:
<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.
+ These are logical groupings of <function>units</function> that are required for userspace functionality. Some are large, such as <filename>multi-user.target</filename>, which defines a full graphical user environment, or more topical, such as <filename>bluetooth.target</filename>, which provides the services a user expects to be available when using Bluetooth devices.
</seg>
</seglistitem>
@@ -427,27 +359,71 @@ Let's look at the different types of units:
<!-- 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.
- </para>
- </footnote> — <command>gdm</command>, <command>kdm</command>, or <command>xdm</command>, depending on the contents of the <filename>/etc/sysconfig/desktop</filename> file.
- </para>
- <para>
- Once finished, the system operates on runlevel 5 and displays a login screen.
- </para>-->
-<!--watchdogs!-->
-
- </section>
-
+ <!--watchdogs!-->
+
+ </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="s1-boot-init-shutdown-run-boot">
<title>Running Additional Programs at Boot Time</title>
<indexterm significance="normal">
@@ -500,7 +476,7 @@ Alias=illustration.service
</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>
+ The <function>[Unit]</function> section has a short 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>.
@@ -539,14 +515,14 @@ Alias=illustration.service
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>
+ <title>Expect legacy commands to be deprecated!</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>
</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:
+ <application>/usr/bin/systemctl</application> does most of the heavy lifting when starting and stopping services, or configuring them to run at boot. Let us look at what <application>systemctl</application> can do:
</para>
<section id="s1-boot-init-shutdown-administration-status">
@@ -585,7 +561,7 @@ Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
<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.
+ 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>. <command>systemctl</command> 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">
@@ -593,29 +569,29 @@ Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
<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>.
+ 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, <command>systemctl</command> 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>With the first command, <command>systemd</command> 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>
+ <screen><command>systemctl mask <replaceable>sshd</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.
+ Masking a service prevents the service from being started manually or automatically. For this example, <command>systemctl</command> is creating a symlink from <filename>/etc/systemd/system/sshd.service</filename> to <filename>/dev/null</filename>. Targets in <filename>/etc/systemd</filename> override those provided by packages in <filename>/lib/systemd</filename>. <command>systemd</command> 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>
+ <title>Getting more from <command>systemd</command></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>.
+ <command>systemctl</command> 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 <command>systemctl</command> features and should help system administrators replace their old workflow in <application>sysVinit</application>.
</para>
<table>
- <title><application>systemd</application> command reference</title>
+ <title><command>systemd</command> command reference</title>
<tgroup cols='3'>
<colspec colname='sysv' />
<colspec colname='systemd' />
@@ -623,10 +599,10 @@ Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
<thead>
<row>
<entry>
- <application>sysVinit</application> command
+ <command>sysVinit</command> command
</entry>
<entry>
- <application>systemd</application> command
+ <command>systemd</command> command
</entry>
<entry>
Notes
More information about the docs-commits
mailing list