[install-guide: 10/18] added comments on systemd compatibility with legacy init scripts

Pete Travis immanetize at fedoraproject.org
Fri Oct 26 05:51:43 UTC 2012


commit 978851d077d17a4876c85f9f8f5445d6845f5802
Author: Pete Travis <immanetize at fedoraproject.org>
Date:   Tue Sep 11 00:31:00 2012 -0600

    added comments on systemd compatibility with legacy init scripts

 en-US/Boot_Init_Shutdown.xml |   15 ++++++++++-----
 1 files changed, 10 insertions(+), 5 deletions(-)
---
diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
index dc777bf..f404b1b 100644
--- a/en-US/Boot_Init_Shutdown.xml
+++ b/en-US/Boot_Init_Shutdown.xml
@@ -203,7 +203,7 @@ A disk may either have a <firstterm>Master Boot Record</firstterm> (MBR) or a <f
  GRUB mounts a designated partition and load its configuration file &mdash; <filename>/boot/grub2/grub.cfg</filename> (for BIOS) or <filename>/boot/efi/EFI/redhat/grub.cfg</filename> (for UEFI) &mdash; 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.
+					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 &mdash; <filename>/boot/vmlinuz-<replaceable>&lt;kernel-version&gt;</replaceable></filename> file (where <filename><replaceable>&lt;kernel-version&gt;</replaceable></filename> corresponds to the kernel version specified in the boot loader's settings).
@@ -276,9 +276,14 @@ A disk may either have a <firstterm>Master Boot Record</firstterm> (MBR) or a <f
 		  </indexterm>
 
 		  <para>
-		    <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.
+		    <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 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>
@@ -365,11 +370,11 @@ Let's look at the different types of units:
 			</segmentedlist>
 
 		     
-<para>
-		    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>
+			  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 these services, 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 <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>&lt;x&gt;</replaceable>.d/</filename> directory, where <replaceable>&lt;x&gt;</replaceable> is the number of the runlevel. For more information on SysV init runlevels, refer to <xref linkend="s1-boot-init-shutdown-sysv" />.
+			   The function and usage of legacy init systems and their configuration files is outside of the scope of this document.
 			</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.


More information about the docs-commits mailing list