[install-guide: 16/18] wrapping up with systemd
Pete Travis
immanetize at fedoraproject.org
Fri Oct 26 05:52:15 UTC 2012
commit c7a0bfb0cd8a3004174fc637f5baf130312e4495
Author: Pete Travis <immanetize at fedoraproject.org>
Date: Sun Oct 14 23:35:04 2012 -0600
wrapping up with systemd
en-US/Boot_Init_Shutdown.xml | 445 ++++++++++++++++++++++++++++++++----------
1 files changed, 344 insertions(+), 101 deletions(-)
---
diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
index a4c6851..f86ce87 100644
--- a/en-US/Boot_Init_Shutdown.xml
+++ b/en-US/Boot_Init_Shutdown.xml
@@ -70,7 +70,7 @@
</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.
+ 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 suit specific needs.
</para>
</section>
@@ -213,7 +213,7 @@
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.
+ 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" />.
@@ -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 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.
+ <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,10 +275,10 @@
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>.
+ 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.
</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.
+ 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.
</para></listitem>
<listitem><para>
The user is presented with a login screen for the freshly booted Linux system.
@@ -287,7 +287,7 @@
<note>
<title>Control Groups</title>
<para>
- 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.
+
</para>
</note>
</section>
@@ -348,62 +348,48 @@
<entry><replaceable>custom</replaceable>.target</entry>
<entry><application>systemd</application> allows any number of custom defined targets.</entry>
</row>
-
- </tbody>
+ </tbody>
</tgroup>
</table>
</section>
-
- <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.
+
+ <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>
-
- <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 <application>systemd</application> 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>
+ </para>
+
+ <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 <application>systemd</application> 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 <application>systemd</application>to monitor the mounting and unmounting of filesystems, and allow <function>units</function> to declare relationships with the filesystems they use.
@@ -433,7 +419,7 @@ Let's look at the different types of units:
<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.
+ 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 services without native configurations, 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 function and usage of legacy init systems and their configuration files is outside of the scope of this document.
@@ -624,50 +610,307 @@ Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
<section id="s1-boot-init-shutdown-administration-systemctl">
<title>Getting more from <application>systemd</application></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.
+ <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>.
</para>
- <segmentedlist>
- <segtitle>command</segtitle>
- <segtitle>result</segtitle>
- <seglistitem>
- <seg>systemctl list-jobs</seg>
- <seg>
- Shows running and waiting jobs; useful for troubleshooting during boot.
- </seg>
- </seglistitem>
- <seglistitem>
- <seg>systemctl list-units -t service</seg>
- <seg>Shows all active services</seg>
- </seglistitem>
- <seglistitem>
- <seg>systemctl list-units -t service --all</seg>
- <seg>Shows all available services</seg>
- </seglistitem>
- <seglistitem>
- <seg>systemctl show -p "Wants" multi-user.target</seg>
- <seg>Shows which services are pulled in by a given target</seg>
- </seglistitem>
- <seglistitem>
- <seg>systemd --test --system --unit=multi-user.target</seg>
- <seg>Simulates booting the system to a given target</seg>
- </seglistitem>
- <seglistitem>
- <seg>systemd-analyze plot > boot.svg</seg>
- <seg>greates a graphical representation of the boot process</seg>
- </seglistitem>
- </segmentedlist>
+ <table>
+ <title><application>systemd</application> command reference</title>
+ <tgroup cols='3'>
+ <colspec colname='sysv' />
+ <colspec colname='systemd' />
+ <colspec colname='notes' />
+ <thead>
+ <row>
+ <entry>
+ <application>sysVinit</application> command
+ </entry>
+ <entry>
+ <application>systemd</application> command
+ </entry>
+ <entry>
+ Notes
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ <command>
+ service sshd start
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl start sshd.service
+ </command>
+ </entry>
+ <entry>
+ Used to start a service (not reboot persistent)
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ service sshd stop
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl stop sshd.service
+ </command>
+ </entry>
+ <entry>
+ Used to stop a service. (not reboot persistent)
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ service sshd restart
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl restart sshd.service
+ </command>
+ </entry>
+ <entry>
+ Used to start and stop a service.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ service sshd reload
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl reload sshd.service
+ </command>
+ </entry>
+ <entry>
+ When supported, reloads the config file without interrupting pending operations.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ service sshd condrestart
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl condrestart sshd.service
+ </command>
+ </entry>
+ <entry>
+ Restarts if the service is already running.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ service sshd status
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl status sshd.service
+ </command>
+ </entry>
+ <entry>
+ Tells whether a service is currently running.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ ls /etc/rc.d/init.d/
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl list-unit-files --type=service
+ </command>
+ </entry>
+ <entry>
+ Lists all available services.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ chkconfig sshd on
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl enable sshd.service
+ </command>
+ </entry>
+ <entry>
+ Always run the service at this target (runlevel.)
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ chkconfig sshd off
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl disable sshd.service
+ </command>
+ </entry>
+ <entry>
+ Do not automatically run the service at this target (runlevel.)
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ chkconfig --list
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl list-units -t service --all
+ </command>
+ </entry>
+ <entry>
+ Print a table of available services and their status.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ chkconfig sshd --list
+ </command>
+ </entry>
+ <entry>
+ <command>
+ ls /etc/systemd/system/*.wants/sshd.service
+ </command>
+ </entry>
+ <entry>
+ Lists the targets that will include the service.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ chkconfig sshd --add
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl daemon-reload
+ </command>
+ </entry>
+ <entry>
+ Used when you create a service file or modify any configuration.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ telinit 3
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl isolate multi-user.target
+ </command>
+ </entry>
+ <entry>
+ Move system into another target (change runlevels.)
+ </entry>
+ </row>
+<row>
+ <entry>
+ <command>
+ [no comparable command]
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl show -p "Wants" multi-user.target
+ </command>
+ </entry>
+ <entry>
+ Lists units pulled in by a given target.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ [no comparable command]
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemctl show -p "After" sshd.service
+ </command>
+ </entry>
+ <entry>
+ Shows dependent services and other targets.
+ </entry>
+ </row>
-
-
-
-<!--
-systemctl for comprehensive view
-sect troubleshooting a slow boot : systemd-analyze-->
-<!-- basically, systemd to sysvinit cheatsheet here. systemctl enable, et al-->
-
-</section>
-
-
-</appendix>
+ <row>
+ <entry>
+ <command>
+ [no comparable command]
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemd --test --system --unit=multi-user.target
+ </command>
+ </entry>
+ <entry>
+ Simulates booting the system to a given target
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ [no comparable command]
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemd-analyze plot > boot.svg
+ </command>
+ </entry>
+ <entry>
+ Generates a diagnostically useful graphical representation of the boot process.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <command>
+ ps xawf -eo pid,user,cgroup,args
+ </command>
+ </entry>
+ <entry>
+ <command>
+ systemd-cgls
+ </command>
+ </entry>
+ <entry>
+ Display control group process tree.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ </section>
+ </section>
+
+
+ </appendix>
More information about the docs-commits
mailing list