[Clfs-commits] [Cross-LFS]Cross-LFS Book branch, systemd, updated. clfs-2.0.0-813-g61ad6c0
git
git at cross-lfs.org
Fri Jan 24 08:51:53 PST 2014
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "Cross-LFS Book".
The branch, systemd has been updated
via 61ad6c0c8e00b862dd750d93918c2b466ea1b3e1 (commit)
via 774f0a37b8d1c946311c0b4c6181db711e93bfb9 (commit)
from 3a85bbdadc162dc77600f2682c504963a22826ff (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 61ad6c0c8e00b862dd750d93918c2b466ea1b3e1
Author: William Harrington <kb0iic at berzerkula.org>
Date: Fri Jan 24 10:53:07 2014 -0600
My eyes finally see the issue. It does have root lock but not 0root lock. Maybe this will fix it for a while.
diff --git a/BOOK/final-system/common/systemd.xml b/BOOK/final-system/common/systemd.xml
index 56de3c2..8e3d79b 100644
--- a/BOOK/final-system/common/systemd.xml
+++ b/BOOK/final-system/common/systemd.xml
@@ -59,7 +59,7 @@ ln -sfv ../lib/systemd/systemd /sbin/init</userinput></screen>
<para os="k">Modify a configuration file which references a group that
doesn't exist:</para>
-<screen os="l"><userinput>sed -i "s at 0root root at root root at g" /usr/lib/tmpfiles.d/legacy.conf</userinput></screen>
+<screen os="l"><userinput>sed -i "s at root lock at root root at g" /usr/lib/tmpfiles.d/legacy.conf</userinput></screen>
</sect2>
commit 774f0a37b8d1c946311c0b4c6181db711e93bfb9
Author: William Harrington <kb0iic at berzerkula.org>
Date: Fri Jan 24 10:52:12 2014 -0600
Add some detailed information regarding systemd usage. It could use some polishing.
diff --git a/BOOK/bootscripts/common/usage.xml b/BOOK/bootscripts/common/usage.xml
index 7378695..7288cf0 100644
--- a/BOOK/bootscripts/common/usage.xml
+++ b/BOOK/bootscripts/common/usage.xml
@@ -15,120 +15,137 @@
<secondary>usage</secondary></indexterm>
<warning>
- <para>Please disregard this page until it can be written.</para>
+ <para>Please disregard this page until it is complete and verified.</para>
</warning>
-<!--
- <para>Linux uses a special booting facility named SysVinit that is
- based on a concept of <emphasis>run-levels</emphasis>. It can be quite
- different from one system to another, so it cannot be assumed that
- because things worked in one particular Linux distribution, they should work
- the same in CLFS too. CLFS has its own way of doing things, but it
- respects generally accepted standards.</para>
-
- <para>SysVinit (which will be referred to as <quote>init</quote> from
- now on) works using a run-levels scheme. There are seven (numbered 0 to 6)
- run-levels (actually, there are more run-levels, but they are for
- special cases and are generally not used. See <filename>init(8)</filename>
- for more details), and each one of those corresponds to the actions the
- computer is supposed to perform when it starts up. The default
- run-level is 3. Here are the descriptions of the different run-levels
- as they are implemented:</para>
-
-<literallayout>0: halt the computer
-1: single-user mode
-2: multi-user mode without networking
-3: multi-user mode with networking
-4: reserved for customization, otherwise does the same as 3
-5: same as 4, it is usually used for GUI login (like X's <command>xdm</command> or KDE's <command>kdm</command>)
-6: reboot the computer</literallayout>
-
- <para>The command used to change run-levels is <command>init
- <replaceable>[runlevel]</replaceable></command>, where
- <replaceable>[runlevel]</replaceable> is the target run-level. For example,
- to reboot the computer, a user could issue the <command>init 6</command>
- command, which is an alias for the <command>reboot</command> command.
- Likewise, <command>init 0</command> is an alias for the
- <command>halt</command> command.</para>
-
- <para>There are a number of directories under <filename
- class="directory">/etc/rc.d</filename> that look like <filename
- class="directory">rc?.d</filename> (where ? is the number of the
- run-level) and <filename class="directory">rcsysinit.d</filename>, all
- containing a number of symbolic links. Some begin with a
- <emphasis>K</emphasis>, the others begin with an
- <emphasis>S</emphasis>, and all of them have two numbers following the
- initial letter. The K means to stop (kill) a service and the S means
- to start a service. The numbers determine the order in which the
- scripts are run, from 00 to 99—the lower the number the earlier it
- gets executed. When <command>init</command> switches to another run-level,
- the appropriate services are either started or stopped, depending on the
- runlevel chosen.</para>
-
- <para>The real scripts are in <filename
- class="directory">/etc/rc.d/init.d</filename>. They do the actual work,
- and the symlinks all point to them. Killing links and starting links point
- to the same script in <filename class="directory">/etc/rc.d/init.d</filename>.
- This is because the scripts can be called with different parameters like
- <option>start</option>, <option>stop</option>, <option>restart</option>,
- <option>reload</option>, and <option>status</option>. When a K link is
- encountered, the appropriate script is run with the <option>stop</option>
- argument. When an S link is encountered, the appropriate script is run
- with the <option>start</option> argument.</para>
-
- <para>There is one exception to this explanation. Links that start
- with an <emphasis>S</emphasis> in the <filename
- class="directory">rc0.d</filename> and <filename
- class="directory">rc6.d</filename> directories will not cause anything
- to be started. They will be called with the parameter
- <option>stop</option> to stop something. The logic behind this
- is that when a user is going to reboot or halt the system, nothing
- needs to be started. The system only needs to be stopped.</para>
-
- <para>These are descriptions of what the arguments make the scripts
- do:</para>
-
- <variablelist>
- <varlistentry>
- <term><option>start</option></term>
- <listitem>
- <para>The service is started.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>stop</option></term>
- <listitem>
- <para>The service is stopped.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>restart</option></term>
- <listitem>
- <para>The service is stopped and then started again.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>reload</option></term>
- <listitem>
- <para>The configuration of the service is updated. This is used
- after the configuration file of a service was modified, when the
- service does not need to be restarted.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term><option>status</option></term>
- <listitem>
- <para>Tells if the service is running and with which PIDs.</para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>Feel free to modify the way the boot process works (after all,
- it is your own CLFS system). The files given here are an example of how
- it can be done.</para>
--->
+
+ <sect2>
+ <title>Introduction to Systemd</title>
+
+
+ <para>Systemd is a system management daemon designed exclusively for the
+ Linux kernel API. In the Linux startup process, it is the first process to
+ execute in user land; therefore, it is also the parent process of all child
+ processes in user land.</para>
+
+ <para>Systemd's initialization instructions for each daemon are recorded in
+ a declarative configuration file rather than a shell script. For
+ inter-process communication, systemd makes Unix domain sockets and D-Bus
+ available to the running daemons. Because systemd tracks processes using
+ Linux cgroups instead of process identifiers (PIDs), daemons cannot "escape"
+ systemd; not even by double-forking. Systemd is also capable of aggressive
+ parallelization.</para>
+
+ <para>Among systemd's auxiliary features are a cron-like job scheduler
+ called systemd Calendar Timers, and an event logging subsystem called
+ journal. The system administrator may choose whether to log system events
+ with systemd or syslog. Systemd's logfile is a binary file. The state of
+ systemd itself can be preserved in a snapshot for future recall.</para>
+
+ <para>Systemd provides a replacement for sysvinit, pm-utils, inetd, acpid,
+ syslog, watchdog, cron and atd, and obsoletes ConsoleKit.</para>
+
+ </sect2>
+
+ <sect2>
+ <title>Systemctl</title>
+
+ <para><command>systemctl</command> is the main command used to introspect
+ and control Systemd.</para>
+
+ <variablelist>
+
+ <varlistentry>
+ <term>List running units:</term>
+ <listitem>
+ <para><command>systemctl</command> or <command>systemctl list-units</command></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>List failed units:</term>
+ <listitem>
+ <para><command>systemctl --failed</command></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>List avilable unit files:</term>
+ <listitem>
+ <para><command>systemctl list-unit-files</command></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Activate a unit immediately:</term>
+ <listitem>
+ <para><command>systemctl start</command> <replaceable>unit</replaceable></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Stop a unit immediately:</term>
+ <listitem>
+ <para><command>systemctl stop </command><replaceable>unit</replaceable></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Restart a unit:</term>
+ <listitem>
+ <para><command>systemctl restart </command><replaceable>unit</replaceable></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Reload unit configuration:</term>
+ <listitem>
+ <para><command>systemctl reload </command><replaceable>unit</replaceable></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Show status of a unit:</term>
+ <listitem>
+ <para><command>systemctl status </command><replaceable>unit</replaceable></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Check if a unit is enabled or disabled:</term>
+ <listitem>
+ <para><command>systemctl is-enabled </command><replaceable>unit</replaceable></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Enable a unit to start during boot:</term>
+ <listitem>
+ <para><command>systemctl enable </command><replaceable>unit</replaceable></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Disable a unit to not start during boot:</term>
+ <listitem>
+ <para><command>systemctl disable </command><replaceable>unit</replaceable></para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Reload systemd and scan for new or changed units:</term>
+ <listitem>
+ <para><command>systemctl daemon-reload</command></para>
+ </listitem>
+ </varlistentry>
+
+ </variablelist>
+
+ <para>For more information regarding systemd, please refer to the systemd
+ and related man-pages and
+ <ulink url="https://fedoraproject.org/wiki/Systemd">Systemd at
+ FedoraProject</ulink> for documentation, examples, features, and other
+ information.</para>
+
+ </sect2>
</sect1>
-----------------------------------------------------------------------
Summary of changes:
BOOK/bootscripts/common/usage.xml | 245 ++++++++++++++++++----------------
BOOK/final-system/common/systemd.xml | 2 +-
2 files changed, 132 insertions(+), 115 deletions(-)
hooks/post-receive
--
Cross-LFS Book
More information about the Clfs-commits
mailing list