[install-guide: 6/18] added an intro to systemd, and described unit types.
Pete Travis
immanetize at fedoraproject.org
Fri Oct 26 05:51:22 UTC 2012
commit edea3a5a8ac6123b7906619cbe95bb376c58e84a
Author: Pete Travis <immanetize at fedoraproject.org>
Date: Sun Jul 29 16:50:54 2012 -0600
added an intro to systemd, and described unit types.
en-US/Boot_Init_Shutdown.xml | 140 +++++++++++++++++++++++++++++++++---------
1 files changed, 111 insertions(+), 29 deletions(-)
---
diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
index e30bced..e4734fe 100644
--- a/en-US/Boot_Init_Shutdown.xml
+++ b/en-US/Boot_Init_Shutdown.xml
@@ -185,10 +185,14 @@
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.
+ 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.
+ </para>
+ </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>
<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.
@@ -217,19 +221,20 @@
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. Configuration of alternative bootloaders is outside of the scope of this document.
+ 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>
<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>
@@ -245,35 +250,112 @@
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.
+ To set up the user environment, the kernel executes the system daemon, <command>systemd</command>.
</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.
+ <section id="s2-boot-init-shutdown-systemd">
+ <title>Booting with <command>systemd</command></title>
+
+ <indexterm significance="preferred">
+ <primary><command>systemd</command></primary>
+ <secondary>role in boot process</secondary>
+ </indexterm>
+
+ <indexterm significance="normal">
+ <primary>boot process</primary>
+ <secondary>stages of</secondary>
+ </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.
+ </para>
+
+
+ <itemizedlist>
+ <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>
+
+ <indexterm significance="normal">
+ <primary>cgroups</primary>
+ <secondary>use by <command>systemd</command></secondary>
+ </indexterm>
+
+ <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>
+
+ <indexterm significance="normal">
+ <primary><command>systemd</command></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.
+Let's look at the different types of units:
</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.
+ <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 <command>systemd</command> 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 <command>systemd</command>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>
+
+
+
+
+ </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.
</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" />.
@@ -423,7 +505,7 @@ S99local -> ../rc.local
Once finished, the system operates on runlevel 5 and displays a login screen.
</para>
- </section>
+ </section>
<section id="s2-boot-init-shutdown-jobs">
<title>Job definitions</title>
More information about the docs-commits
mailing list