[install-guide: 7/18] correcting some tags
Pete Travis
immanetize at fedoraproject.org
Fri Oct 26 05:51:28 UTC 2012
commit 2af34cacad157ccb0d1fda82a5f75de980bc4641
Author: Pete Travis <immanetize at fedoraproject.org>
Date: Mon Sep 10 22:39:04 2012 -0600
correcting some tags
en-US/Boot_Init_Shutdown.xml | 132 ++++++++++++++++++++++++------------------
1 files changed, 76 insertions(+), 56 deletions(-)
---
diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
index e4734fe..0f6e868 100644
--- a/en-US/Boot_Init_Shutdown.xml
+++ b/en-US/Boot_Init_Shutdown.xml
@@ -51,13 +51,13 @@
</listitem>
<listitem>
<para>
- The kernel transfers control of the boot process to the system daemon, <command>systemd</command>.
+ The kernel transfers control of the boot process to the system daemon, <application>systemd</application>.
</para>
</listitem>
<listitem>
<para>
- <command>systemd</command> loads needed services and user-space tools, and mounts filesystems listed in <filename>/etc/fstab</filename>.
+ <application>systemd</application> loads needed services and user-space tools, and mounts filesystems listed in <filename>/etc/fstab</filename>.
</para>
</listitem>
@@ -187,10 +187,11 @@
<para>
GRUB has the advantage of being able to read ext2, ext3, and ext4 as well as virtual devices such as LVM.
</para>
- <footnote> <para>
- GRUB reads ext3 and ext4 file systems as ext2, disregarding the journal file.
+ <!-- I want to verify this!
+ <footnote> <para>
+ GRUB reads ext3 and ext4 file systems as ext2, disregarding the journal file.
</para>
- </footnote>
+ </footnote>-->
<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>
@@ -250,15 +251,15 @@
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, <command>systemd</command>.
+ 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 <command>systemd</command></title>
+ <title>Booting with <application>systemd</application></title>
<indexterm significance="preferred">
- <primary><command>systemd</command></primary>
+ <primary><application>systemd</application></primary>
<secondary>role in boot process</secondary>
</indexterm>
@@ -268,33 +269,40 @@
</indexterm>
<para>
- <command>systemd</command> is the first process started by the kernel. It replaces the venerable <command>SysVinit</command> program (also called <command>init</command>) and the newer <command>Upstart</command> init system. <command>systemd</command> coordinates the rest of the boot process and configures the environment for the user.
+ <application>systemd</application> is the first process started by the kernel. It replaces the venerable <command>SysVinit</command> program (also called <command>init</command>) and the newer <command>Upstart</command> init system. <application>systemd</application> coordinates the rest of the boot process and configures the environment for the user.
</para>
-
- <itemizedlist>
- <listitem><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.
</para></listitem>
-
- <indexterm significance="normal">
- <primary>cgroups</primary>
- <secondary>use by <command>systemd</command></secondary>
- </indexterm>
+ </itemizedlist>
+
+ </section>
- <listitem><para>
- New process started by <command>systemd</command> 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 or by a <xref linkend=''>messaging bus</xref>.
- </para></listitem>
-
+ <section id="s2-boot-init-shutdown-systemd-units">
+ <title><application>systemd</application> <function>units</function></title>
<indexterm significance="normal">
- <primary><command>systemd</command></primary>
+ <primary><application>systemd</application></primary>
<secondary>units</secondary>
</indexterm>
<para>
- Functions administered by <command>systemd</command> 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 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>
@@ -310,7 +318,7 @@ Let's look at the different types of units:
<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 <command>systemd</command> should monitor it.
+ 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>
@@ -324,7 +332,7 @@ Let's look at the different types of units:
<seglistitem>
<seg><function>mount</function></seg>
<seg>
- These <function>units</function> allow <command>systemd</command>to monitor the mounting and unmounting of filesystems, and allow <function>units</function> to declare relationships with the filesystems they use.
+ 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>
@@ -349,13 +357,9 @@ Let's look at the different types of units:
</seglistitem>
</segmentedlist>
-
-
-
- </itemizedlist>
-
+
<para>
- When <command>systemd</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.
+ When <application>systemd</application> 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" />.
@@ -578,34 +582,48 @@ exec /sbin/mingetty tty2
</section>
- <section id="s1-boot-init-shutdown-sysv">
- <title>SysV Init Runlevels</title>
+ <section id="s1-boot-init-shutdown-targets">
+ <title>systemd targets</title>
<indexterm significance="normal">
- <primary>SysV init</primary>
- <see><command>init</command> command</see>
-
- </indexterm>
- <indexterm significance="normal">
- <primary><command>init</command> command</primary>
- <secondary>runlevels</secondary>
- <tertiary>directories for</tertiary>
-
- </indexterm>
+ <primary>systemd</primary>
+ <secondary><function>targets</function></secondary>
+ </indexterm>
<indexterm significance="normal">
- <primary><command>init</command> command</primary>
- <secondary>SysV init</secondary>
- <tertiary>definition of</tertiary>
-
- </indexterm>
+ <primary>runlevels</primary>
+ </indexterm>
+
<indexterm significance="normal">
- <primary><command>init</command> command</primary>
- <secondary>configuration files</secondary>
- <tertiary><filename>/etc/inittab</filename> </tertiary>
-
- </indexterm>
+ <primary><command>init</command> command</primary>
+ <secondary>configuration files</secondary>
+ <tertiary><filename>/etc/inittab</filename> </tertiary>
+ </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.
- </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. The following table shows some standard preconfigured targets, the <application>sysVinit</application> <function>runlevels</function> they resemble, the use case they address, and examples of targets they might require.
+ </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>run</entry>
+ <entry></entry>
+ <entry>
+ graphical display
+ </entry>
+
+ </row>
<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>
@@ -615,7 +633,9 @@ exec /sbin/mingetty tty2
<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>
- <section id="s2-init-boot-shutdown-rl">
+
+
+ <section id="s2-init-boot-shutdown-rl">
<title>Runlevels</title>
<indexterm significance="normal">
<primary>runlevels</primary>
More information about the docs-commits
mailing list