commit 01feea1c1ca7962eaebdd8d552ad594a54e3128f
Merge: 9477b03 07b2bc4
Author: Jack Reed <jreed(a)redhat.com>
Date: Thu Nov 1 16:02:38 2012 +1000
Tweaks to Boot Process, Init, and Shutdown
en-US/Boot_Init_Shutdown.xml | 191 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 191 insertions(+), 0 deletions(-)
---
diff --cc en-US/Boot_Init_Shutdown.xml
index f86ce87,73b5cfc..29d4d58
--- a/en-US/Boot_Init_Shutdown.xml
+++ b/en-US/Boot_Init_Shutdown.xml
@@@ -177,28 -177,28 +177,50 @@@
<section id="s2-boot-init-shutdown-loader">
<title>The Boot Loader</title>
<section id="s2-boot-init-shutdown-loader-bios">
++<<<<<<< HEAD
+ <title>The GRUB boot loader for x86 systems</title>
++=======
+ <title>The GRUB2 boot loader for x86 systems</title>
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
<indexterm significance="normal">
<primary>boot process</primary>
<secondary>stages of</secondary>
<tertiary>boot loader</tertiary>
</indexterm>
<indexterm significance="normal">
++<<<<<<< HEAD
+ <primary>GRUB</primary>
+ <secondary>role in boot process</secondary>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>GRUB</primary>
+ <seealso>boot loaders</seealso>
+ </indexterm>
+ <para>
+ 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>
+ <application>GRUB</application> version 2 has the advantage of being
able to read a variety of open filesystems, as well as virtual devices such as
<application>mdadm</application> RAID arrays and
<application>LVM</application> .
+ </para>
+ <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.
++=======
+ <primary>GRUB2</primary>
+ <secondary>role in boot process</secondary>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>GRUB2</primary>
+ <seealso>boot loaders</seealso>
+ </indexterm>
+ <para>
+ The system loads GRUB2 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>
+ <application>GRUB2</application> has the advantage of being able to
read a variety of open filesystems, as well as virtual devices such as
<application>mdadm</application> RAID arrays and
<application>LVM</application> .
+ </para>
+ <para>
+ GRUB2 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.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</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>.
Typically, if no key is pressed, the boot loader loads the default selection after a
configurable period of time has passed.
@@@ -216,7 -216,7 +238,11 @@@
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>
++<<<<<<< HEAD
+ For a more detailed overview of the GRUB boot loader, refer to <xref
linkend="ch-grub" />.
++=======
+ For a more detailed overview of the GRUB2 boot loader, refer to <xref
linkend="ch-grub" />.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</para>
</section>
<section id="s3-boot-init-shutdown-other-architectures">
@@@ -243,7 -243,7 +269,11 @@@
<para>
When the kernel is loaded, it immediately initializes and configures the
computer's memory and configures the various hardware attached to the system,
including all processors, I/O subsystems, and storage devices. It then loads the
<filename>initramfs</filename> image(s) from disk and decompresses it into a
<systemitem>tmpfs</systemitem> as the acting root filesystem. The
<filename>initramfs</filename> contains programs and kernel modules required
to continue booting the system, such as those used to initialize virtual devices related
to file systems, like LVM or software RAID.
</para>
++<<<<<<< HEAD
+ <para>The kernel uses the <filename>initramfs</filename> to continue
the boot process, and when the final root device is available, the
<filename>initramfs</filename> is unmounted and the real root filesystem is
mounted in it's place.
++=======
+ <para>The kernel uses the <filename>initramfs</filename> to continue
the boot process, and when the final root device is available, the
<filename>initramfs</filename> is unmounted and the real root filesystem is
mounted in its place.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</para>
<para>
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.
@@@ -266,7 -266,7 +296,11 @@@
<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>
++<<<<<<< HEAD
+ <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.
++=======
+ <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.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</para>
<itemizedlist>
@@@ -275,7 -275,7 +309,11 @@@
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>
++<<<<<<< HEAD
+ 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.
++=======
+ New processes 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 allotted by the kernel,
and the restrictions are inherited by newly spawned processes. Communication with outside
processes will be handled by the kernel through sockets.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</para></listitem>
<listitem><para>
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.
@@@ -284,75 -284,7 +322,79 @@@
The user is presented with a login screen for the freshly booted Linux system.
</para></listitem>
</itemizedlist>
++<<<<<<< HEAD
+ <note>
+ <title>Control Groups</title>
+ <para>
+
+ </para>
+ </note>
+ </section>
+
+ <section id="s1-boot-init-shutdown-targets">
+ <title>systemd targets</title>
+ <indexterm significance="normal">
+ <primary>systemd</primary>
+ <secondary><function>targets</function></secondary>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>runlevels</primary>
+ </indexterm>
+ <indexterm significance="normal">
+ <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>
+ <para>
+ The following table shows some standard preconfigured targets, the
<application>sysVinit</application> <function>runlevels</function>
they resemble and the use case they address.
+ </para>
+ <table>
+ <title>Predefined <application>systemd</application>
targets</title>
+ <tgroup cols="3" align="left" colsep="1"
rowsep="1">
+ <colspec colname="runlevel" colnum="1" />
+ <colspec colname="target" colnum="2" />
+ <colspec colname="usage" colnum="3" />
+ <thead>
+ <row>
+ <entry>Runlevel</entry>
+ <entry>Target</entry>
+ <entry>Usage</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>1,single</entry>
+ <entry>rescue.target</entry>
+ <entry>single user mode, for recovery of critical system components or
configuration</entry>
+ </row>
+ <row>
+ <entry>3</entry>
+ <entry>multi-user.target</entry>
+ <entry>Non-graphical multi-user console access, via local TTYs
or network.</entry>
+ </row>
+ <row>
+ <entry>5</entry>
+ <entry>graphical.target</entry>
+ <entry>A GUI session. Typically provides the user with a fully
featured desktop environment.</entry>
+ </row>
+ <row>
+ <entry>4</entry>
+
<entry><replaceable>custom</replaceable>.target</entry>
+ <entry><application>systemd</application> allows
any number of custom defined targets.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </section>
++=======
+ </section>
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
<section id="s2-boot-init-shutdown-systemd-units">
<title><application>systemd</application>
<function>units</function></title>
@@@ -361,7 -293,7 +403,11 @@@
<secondary>units</secondary>
</indexterm>
<para>
++<<<<<<< HEAD
+ 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.
++=======
+ 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 described 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 its dependencies.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
Let's look at the different types of units:
</para>
@@@ -371,7 -303,7 +417,11 @@@
<seglistitem>
<seg><function>socket</function></seg>
<seg>
++<<<<<<< HEAD
+ 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>.
++=======
+ These provide an endpoint for interprocess communication. Messages can be
transported through files, or network or Unix sockets. Each
<function>socket</function> has a corresponding
<function>service</function>.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</seg>
</seglistitem>
@@@ -406,7 -338,7 +456,11 @@@
<seglistitem>
<seg><function>target</function></seg>
<seg>
++<<<<<<< HEAD
+ 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.
++=======
+ These are logical groupings of <function>units</function> that are
required for userspace functionality. Some are large, such as
<filename>multi-user.target</filename>, which defines a full graphical user
environment, or more topical, such as <filename>bluetooth.target</filename>,
which provides the services a user expects to be available when using Bluetooth devices.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</seg>
</seglistitem>
@@@ -427,27 -359,71 +481,95 @@@
<!-- section covering symlinks for targets. -->
<!--note about managing services-->
++<<<<<<< HEAD
+ <!--paragraphs describing various runlevels:
+ <para>
+ After the <command>init</command> command has progressed through the
appropriate <filename>rc</filename> directory for the runlevel,
<application>Upstart</application> forks an
<command>/sbin/mingetty</command> process for each virtual console (login
prompt) allocated to the runlevel by the job definition in the
<filename>/etc/event.d</filename> directory. Runlevels 2 through 5 have all
six virtual consoles, while runlevel 1 (single user mode) has one, and runlevels 0 and 6
have none. The <command>/sbin/mingetty</command> process opens communication
pathways to <firstterm>tty</firstterm> devices<footnote> <para>
+ Refer to the Fedora Deployment Guide for more information about
<filename>tty</filename> devices.
+ </para>
+ </footnote>, sets their modes, prints the login prompt, accepts the
user's username and password, and initiates the login process.
+ </para>
+
+ <para>
+ In runlevel 5, <application>Upstart</application> runs a script called
<filename>/etc/X11/prefdm</filename>. The
<filename>prefdm</filename> script executes the preferred X display
manager<footnote> <para>
+ Refer to the Fedora Deployment Guide for more information about display managers.
+ </para>
+ </footnote> — <command>gdm</command>,
<command>kdm</command>, or <command>xdm</command>, depending on
the contents of the <filename>/etc/sysconfig/desktop</filename> file.
+ </para>
+ <para>
+ Once finished, the system operates on runlevel 5 and displays a login screen.
+ </para>-->
+<!--watchdogs!-->
+
+ </section>
+
++=======
+ <!--watchdogs!-->
+
+ </section>
+
+ <section id="s1-boot-init-shutdown-targets">
+ <title>systemd targets</title>
+ <indexterm significance="normal">
+ <primary>systemd</primary>
+ <secondary><function>targets</function></secondary>
+ </indexterm>
+ <indexterm significance="normal">
+ <primary>runlevels</primary>
+ </indexterm>
+ <indexterm significance="normal">
+ <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>
+ <para>
+ The following table shows some standard preconfigured targets, the
<application>sysVinit</application> <function>runlevels</function>
they resemble and the use case they address.
+ </para>
+ <table>
+ <title>Predefined <application>systemd</application>
targets</title>
+ <tgroup cols="3" align="left" colsep="1"
rowsep="1">
+ <colspec colname="runlevel" colnum="1" />
+ <colspec colname="target" colnum="2" />
+ <colspec colname="usage" colnum="3" />
+ <thead>
+ <row>
+ <entry>Runlevel</entry>
+ <entry>Target</entry>
+ <entry>Usage</entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>1,single</entry>
+ <entry>rescue.target</entry>
+ <entry>single user mode, for recovery of critical system components or
configuration</entry>
+ </row>
+ <row>
+ <entry>3</entry>
+ <entry>multi-user.target</entry>
+ <entry>Non-graphical multi-user console access, via local TTYs
or network.</entry>
+ </row>
+ <row>
+ <entry>5</entry>
+ <entry>graphical.target</entry>
+ <entry>A GUI session. Typically provides the user with a fully
featured desktop environment.</entry>
+ </row>
+ <row>
+ <entry>4</entry>
+
<entry><replaceable>custom</replaceable>.target</entry>
+ <entry><application>systemd</application> allows
any number of custom defined targets.</entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+
+ </section>
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
<section id="s1-boot-init-shutdown-run-boot">
<title>Running Additional Programs at Boot Time</title>
<indexterm significance="normal">
@@@ -475,32 -451,32 +597,60 @@@
<see><command>setserial</command> command</see>
</indexterm>
++<<<<<<< HEAD
+
+ <para>
+ Historically, those wishing to execute additional programs at boot could insert
commands into <filename>/etc/rc.local</filename>. While
<application>systemd</application> will use this file, writing
<function>unit</function> files can be simple, effective, and much more
flexible. Consider this example <function>unit</function> file:
+ </para>
+ <example>
+ <title>An example of a simple unit file</title>
+ <programlisting>
+ #cat /lib/systemd/system/example.service
+ [Unit]
+ Description=A service that executes a user script on startup
+ Wants=network.target
+
+
+ [Service]
+ ExecStart=/opt/domain/bin/example
+ Type=oneshot
+
+ [Install]
+ WantedBy=multi-user.target
+ Alias=illustration.service
+
++=======
+
+ <para>
+ Historically, those wishing to execute additional programs at boot could insert
commands into <filename>/etc/rc.local</filename>. While
<application>systemd</application> will use this file, writing
<function>unit</function> files can be simple, effective, and much more
flexible. Consider this example <function>unit</function> file:
+ </para>
+ <example>
+ <title>An example of a simple unit file</title>
+ <programlisting>
+#cat /lib/systemd/system/example.service
+[Unit]
+Description=A service that executes a user script on startup
+Wants=network.target
+
+
+[Service]
+ExecStart=/opt/domain/bin/example
+Type=oneshot
+
+[Install]
+WantedBy=multi-user.target
+Alias=illustration.service
+
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</programlisting>
</example>
<para>
++<<<<<<< HEAD
+ The <function>[Unit]</function> section has a shord description, and
dependencies on other targets. The various types of dependencies and attributes used in
this section are described in <command>man systemd.unit</command>
++=======
+ The <function>[Unit]</function> section has a short description, and
dependencies on other targets. The various types of dependencies and attributes used in
this section are described in <command>man systemd.unit</command>
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</para>
<para>
The <function>[Service]</function> section establishes the actual
command to be executed, and describes how <application>systemd</application>
should handle the process. Options for this section are described in <command>man
systemd.service</command>.
@@@ -539,14 -515,14 +689,22 @@@
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>
++<<<<<<< HEAD
+ <title>Expect legacy commands to be depricated!</title>
++=======
+ <title>Expect legacy commands to be deprecated!</title>
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
<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>
++<<<<<<< HEAD
+ <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:
++=======
+ <application>/usr/bin/systemctl</application> does most of the heavy
lifting when starting and stopping services, or configuring them to run at boot. Let us
look at what <application>systemctl</application> can do:
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</para>
<section id="s1-boot-init-shutdown-administration-status">
@@@ -585,7 -561,7 +743,11 @@@ Sep 20 22:56:55 fqdn.fedora.lan sshd[97
<screen><command>systemctl restart
sshd.service</command></screen>
<para>
++<<<<<<< HEAD
+ 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.
++=======
+ 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>.
<command>systemctl</command> might report helpful information about a
misbehaving application in the <function>status</function>, but the
application's own logs are more relevant.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</para>
</section>
<section id="s1-boot-init-shutdown-administration-enable">
@@@ -593,29 -569,29 +755,51 @@@
<screen><command>systemctl enable
sshd.service</command></screen>
<screen><command>systemctl disable
sshd.service</command></screen>
<para>
++<<<<<<< HEAD
+ A service that is enabled will start automatically when the system
boots. A service that is disabled will not start at boot. These commands are manipulating
symbolic links in <filename>/lib/systemd/system/</filename> and
<filename>/lib/systemd/user/</filename> while retaining the relationships with
other units established in the <filename>.service</filename> file. 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>.
++=======
+ A service that is enabled will start automatically when the system
boots. A service that is disabled will not start at boot. These commands are manipulating
symbolic links in <filename>/lib/systemd/system/</filename> and
<filename>/lib/systemd/user/</filename> while retaining the relationships with
other units established in the <filename>.service</filename> file. While the
symlinks can be manipulated manually, <command>systemctl</command> also
rebuilds the <application>systemd</application> configuration, saving the
extra step of invoking <command>systemctl daemon-reload</command>.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</para>
</section>
<section id="s1-boot-init-shutdown-administration-kill">
<title>Killing and Masking services</title>
<screen><command>systemctl kill
sshd.service</command></screen>
<screen><command>systemctl kill -s USR1
<replaceable>daemon</replaceable>.service</command></screen>
++<<<<<<< HEAD
+ <para>With the first command,
<application>systemd</application> kills all processes and child processes of
the <application>sshd</application> service. The second command demonstrates
how any Unix signal can be sent to the processes of a service.
+ </para>
+ <screen><command>systemctl mask
<replaceable>daemon</replaceable>.service</command></screen>
+ <para>
+ Masking a service prevents the service from being started manually or
automatically. For this example, <application>systemctl</application> is
creating a symlink from
<filename>/etc/systemd/system/daemon.service</filename> to /dev/null. Targets
in <filename>/etc/systemd</filename> override those provided by packages in
<filename>/lib/systemd</filename>.
<application>systemd</application> recognizes the symlink and will not start
the service.
++=======
+ <para>With the first command, <command>systemd</command>
kills all processes and child processes of the <application>sshd</application>
service. The second command demonstrates how any Unix signal can be sent to the processes
of a service.
+ </para>
+ <screen><command>systemctl mask
<replaceable>sshd</replaceable>.service</command></screen>
+ <para>
+ Masking a service prevents the service from being started manually or
automatically. For this example, <command>systemctl</command> is creating a
symlink from <filename>/etc/systemd/system/sshd.service</filename> to
<filename>/dev/null</filename>. Targets in
<filename>/etc/systemd</filename> override those provided by packages in
<filename>/lib/systemd</filename>. <command>systemd</command>
recognizes the symlink and will not start the service.
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</para>
</section>
<section id="s1-boot-init-shutdown-administration-systemctl">
++<<<<<<< HEAD
+ <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 and
should help system administrators replace their old workflow in
<application>sysVinit</application>.
+ </para>
+ <table>
+ <title><application>systemd</application> command
reference</title>
++=======
+ <title>Getting more from
<command>systemd</command></title>
+ <!--rewrite with the goal of still troubleshooting sshd?-->
+ <para>
+ <command>systemctl</command> 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
<command>systemctl</command> features and should help system administrators
replace their old workflow in <application>sysVinit</application>.
+ </para>
+ <table>
+ <title><command>systemd</command> command reference</title>
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
<tgroup cols='3'>
<colspec colname='sysv' />
<colspec colname='systemd' />
@@@ -623,10 -599,10 +807,17 @@@
<thead>
<row>
<entry>
++<<<<<<< HEAD
+ <application>sysVinit</application> command
+ </entry>
+ <entry>
+ <application>systemd</application> command
++=======
+ <command>sysVinit</command> command
+ </entry>
+ <entry>
+ <command>systemd</command> command
++>>>>>>> 07b2bc43e7d68602cb1a268e1700afc427bd8453
</entry>
<entry>
Notes