[install-guide: 14/18] Beginning a crash course in systemctl
Pete Travis
immanetize at fedoraproject.org
Fri Oct 26 05:52:04 UTC 2012
commit 393d0c6922decaa57f3953d914a5c9b8dd600d5c
Author: Pete Travis <immanetize at fedoraproject.org>
Date: Fri Sep 21 00:25:37 2012 -0600
Beginning a crash course in systemctl
en-US/Boot_Init_Shutdown.xml | 103 ++++++++++++++++++++++++++++++++++++++---
1 files changed, 95 insertions(+), 8 deletions(-)
---
diff --git a/en-US/Boot_Init_Shutdown.xml b/en-US/Boot_Init_Shutdown.xml
index 577b832..2e61b11 100644
--- a/en-US/Boot_Init_Shutdown.xml
+++ b/en-US/Boot_Init_Shutdown.xml
@@ -228,8 +228,8 @@
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">
+ </section>
+ <section id="s2-boot-init-shutdown-kernel">
<title>The Kernel</title>
<indexterm significance="normal">
<primary>boot process</primary>
@@ -251,8 +251,8 @@
<para>
To set up the user environment, the kernel executes the system daemon, <application>systemd</application>.
</para>
- </section>
- <section id="s2-boot-init-shutdown-systemd">
+ </section>
+ <section id="s2-boot-init-shutdown-systemd">
<title>Booting with <application>systemd</application></title>
<indexterm significance="preferred">
<primary><application>systemd</application></primary>
@@ -285,7 +285,10 @@
</para></listitem>
</itemizedlist>
<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>
@@ -302,8 +305,9 @@
<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>
@@ -522,11 +526,94 @@ Alias=illustration.service
</section>
-
- <!-- basically, systemd to sysvinit cheatsheet here. systemctl enable, et al-->
+ <section id="s1-boot-init-shutdown-administration">
+ <title>Administering services with <application>systemd</application></title>
+ <indexterm significance="normal">
+ <primary>systemd</primary>
+ <secondary>administration utilites</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>systemctl</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>chkconfig</primary>
+ <see>systemctl</see>
+ </indexterm>
+
+ <indexterm>
+ <primary><command>service</command> command</primary>
+ <see>systemctl</see>
+ </indexterm>
+
+
+
+ <para>
+ 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>
+ <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:
+ </para>
+
+ <section id="s1-boot-init-shutdown-administration-status">
+ <title>Checking up on services</title>
+ <screen>
+
+<![CDATA[
+[root at fedora ~]# systemctl status sshd.service
+sshd.service - OpenSSH server daemon
+ Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
+ Active: inactive (dead) since Thu, 20 Sep 2012 22:56:55 -0600; 17s ago
+ Process: 971 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=0/SUCCESS)
+ Process: 941 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
+ CGroup: name=systemd:/system/sshd.service
+
+Sep 20 19:17:02 fqdn.fedora.lan sshd[23515]: pam_unix(sshd:auth): authentication ...3
+Sep 20 19:17:03 fqdn.fedora.lan sshd[23515]: Failed password for invalid user usr...2
+Sep 20 19:17:04 fqdn.fedora.lan sshd[23515]: Received disconnect from 192.168.1.....]
+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: Invalid user db2inst1 from 192.168.1...]
+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: input_userauth_request: invalid user...]
+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: pam_unix(sshd:auth): check pass; use...n
+Sep 20 19:17:06 fqdn.fedora.lan sshd[23517]: pam_unix(sshd:auth): authentication ...3
+Sep 20 19:17:08 fqdn.fedora.lan sshd[23517]: Failed password for invalid user db2...2
+Sep 20 19:17:08 fqdn.fedora.lan sshd[23517]: Received disconnect from 192.168.1.....]
+Sep 20 22:56:55 fqdn.fedora.lan sshd[971]: Received signal 15; terminating.
+]]>
+ </screen>
+ <para>
+ The command <command>systemctl status <replaceable>sshd</replaceable>.service</command> can tell us much more than if the service is running. In this example with <application>sshd</application>, we can see that the service is <function>enabled</function> but not <function>active</function>. We know how the service was invoked, what the PID was, and when it was stopped. We can also see the last portion of the service's log.
+ </para>
+ </section>
+ <section id="s1-boot-init-shutdown-administration-start">
+ <title>Starting and stopping services</title>
+ <screen><command>systemctl start sshd.service</command></screen>
+ <screen><command>systemctl stop sshd.service</command></screen>
+ <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.
+ </para>
+ </section>
+ <section id="s1-boot-init-shutdown-administration-enable">
+ <title>Running services automatically</title>
+ <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. These commands are manipulating symbolic links in <filename>/lib/systemd/system/</filename> and <filename>/lib/systemd/user/</filename>. 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>.
+ </para>
+ </section>
+
+<!-- basically, systemd to sysvinit cheatsheet here. systemctl enable, et al-->
<!-- </section>-->
</appendix>
-
More information about the docs-commits
mailing list