Ignore:
File:
1 edited

Legend:

Unmodified
Added
Removed

  • BOOK/bootscripts/common/usage.xml

    r24d7e06 raa18ac0  
    99  <?dbhtml filename="usage.html"?>
    1010
    11   <title>How does Systemd work?</title>
     11  <title>How Do These Bootscripts Work?</title>
    1212
    1313  <indexterm zone="ch-scripts-usage">
    14     <primary sortas="a-systemd-usage">Systemd usage</primary>
     14    <primary sortas="a-Bootscripts">Bootscripts</primary>
    1515  <secondary>usage</secondary></indexterm>
    1616
    17   <warning>
    18     <para>Please disregard this page until it is complete and verified.</para>
    19   </warning>
     17  <para>Linux uses a special booting facility named SysVinit that is
     18  based on a concept of <emphasis>run-levels</emphasis>. It can be quite
     19  different from one system to another, so it cannot be assumed that
     20  because things worked in one particular Linux distribution, they should work
     21  the same in CLFS too. CLFS has its own way of doing things, but it
     22  respects generally accepted standards.</para>
    2023
    21   <sect2>
    22     <title>Introduction to Systemd</title>
     24  <para>SysVinit (which will be referred to as <quote>init</quote> from
     25  now on) works using a run-levels scheme. There are seven (numbered 0 to 6)
     26  run-levels (actually, there are more run-levels, but they are for
     27  special cases and are generally not used. See <filename>init(8)</filename>
     28  for more details), and each one of those corresponds to the actions the
     29  computer is supposed to perform when it starts up. The default
     30  run-level is 3. Here are the descriptions of the different run-levels
     31  as they are implemented:</para>
    2332
    24  
    25     <para>Systemd is a system management daemon designed exclusively for the
    26     Linux kernel API. In the Linux startup process, it is the first process to
    27     execute in user land; therefore, it is also the parent process of all child
    28     processes in user land.</para>
     33<literallayout>0: halt the computer
     341: single-user mode
     352: multi-user mode without networking
     363: multi-user mode with networking
     374: reserved for customization, otherwise does the same as 3
     385: same as 4, it is usually used for GUI login (like X's <command>xdm</command> or KDE's <command>kdm</command>)
     396: reboot the computer</literallayout>
    2940
    30     <para>Systemd's initialization instructions for each daemon are recorded in
    31     a declarative configuration file rather than a shell script. For
    32     inter-process communication, systemd makes Unix domain sockets and D-Bus
    33     available to the running daemons. Because systemd tracks processes using
    34     Linux cgroups instead of process identifiers (PIDs), daemons cannot "escape"
    35     systemd; not even by double-forking. Systemd is also capable of aggressive
    36     parallelization.</para>
     41  <para>The command used to change run-levels is <command>init
     42  <replaceable>[runlevel]</replaceable></command>, where
     43  <replaceable>[runlevel]</replaceable> is the target run-level. For example,
     44  to reboot the computer, a user could issue the <command>init 6</command>
     45  command, which is an alias for the <command>reboot</command> command.
     46  Likewise, <command>init 0</command> is an alias for the
     47  <command>halt</command> command.</para>
    3748
    38     <para>Among systemd's auxiliary features are a cron-like job scheduler
    39     called systemd Calendar Timers, and an event logging subsystem called
    40     journal. The system administrator may choose whether to log system events
    41     with systemd or syslog. Systemd's logfile is a binary file. The state of
    42     systemd itself can be preserved in a snapshot for future recall.</para>
     49  <para>There are a number of directories under <filename
     50  class="directory">/etc/rc.d</filename> that look like <filename
     51  class="directory">rc?.d</filename> (where ? is the number of the
     52  run-level) and <filename class="directory">rcsysinit.d</filename>, all
     53  containing a number of symbolic links. Some begin with a
     54  <emphasis>K</emphasis>, the others begin with an
     55  <emphasis>S</emphasis>, and all of them have two numbers following the
     56  initial letter. The K means to stop (kill) a service and the S means
     57  to start a service. The numbers determine the order in which the
     58  scripts are run, from 00 to 99&mdash;the lower the number the earlier it
     59  gets executed. When <command>init</command> switches to another run-level,
     60  the appropriate services are either started or stopped, depending on the
     61  runlevel chosen.</para>
    4362
    44     <para>Systemd provides a replacement for sysvinit, pm-utils, inetd, acpid,
    45     syslog, watchdog, cron and atd, and obsoletes ConsoleKit.</para>
     63  <para>The real scripts are in <filename
     64  class="directory">/etc/rc.d/init.d</filename>. They do the actual work,
     65  and the symlinks all point to them. Killing links and starting links point
     66  to the same script in <filename class="directory">/etc/rc.d/init.d</filename>.
     67  This is because the scripts can be called with different parameters like
     68  <option>start</option>, <option>stop</option>, <option>restart</option>,
     69  <option>reload</option>, and <option>status</option>. When a K link is
     70  encountered, the appropriate script is run with the <option>stop</option>
     71  argument. When an S link is encountered, the appropriate script is run
     72  with the <option>start</option> argument.</para>
    4673
    47   </sect2>
     74  <para>There is one exception to this explanation. Links that start
     75  with an <emphasis>S</emphasis> in the <filename
     76  class="directory">rc0.d</filename> and <filename
     77  class="directory">rc6.d</filename> directories will not cause anything
     78  to be started. They will be called with the parameter
     79  <option>stop</option> to stop something. The logic behind this
     80  is that when a user is going to reboot or halt the system, nothing
     81  needs to be started. The system only needs to be stopped.</para>
    4882
    49   <sect2>
    50     <title>Systemctl</title>
     83  <para>These are descriptions of what the arguments make the scripts
     84  do:</para>
    5185
    52     <para><command>systemctl</command> is the main command used to introspect
    53      and control Systemd.</para>
     86  <variablelist>
     87    <varlistentry>
     88      <term><option>start</option></term>
     89      <listitem>
     90        <para>The service is started.</para>
     91      </listitem>
     92    </varlistentry>
    5493
    55     <variablelist>
     94    <varlistentry>
     95      <term><option>stop</option></term>
     96      <listitem>
     97        <para>The service is stopped.</para>
     98      </listitem>
     99    </varlistentry>
    56100
    57       <varlistentry>
    58         <term>List running units:</term>
    59         <listitem>
    60           <para><command>systemctl</command> or <command>systemctl list-units</command></para>
    61         </listitem>
    62       </varlistentry>
     101    <varlistentry>
     102      <term><option>restart</option></term>
     103      <listitem>
     104        <para>The service is stopped and then started again.</para>
     105      </listitem>
     106    </varlistentry>
    63107
    64       <varlistentry>
    65         <term>List failed units:</term>
    66         <listitem>
    67           <para><command>systemctl --failed</command></para>
    68         </listitem>
    69       </varlistentry>
     108    <varlistentry>
     109      <term><option>reload</option></term>
     110      <listitem>
     111        <para>The configuration of the service is updated. This is used
     112        after the configuration file of a service was modified, when the
     113        service does not need to be restarted.</para>
     114      </listitem>
     115    </varlistentry>
    70116
    71       <varlistentry>
    72         <term>List available unit files:</term>
    73         <listitem>
    74           <para><command>systemctl list-unit-files</command></para>
    75         </listitem>
    76       </varlistentry>
     117    <varlistentry>
     118      <term><option>status</option></term>
     119      <listitem>
     120        <para>Tells if the service is running and with which PIDs.</para>
     121      </listitem>
     122    </varlistentry>
     123  </variablelist>
    77124
    78       <varlistentry>
    79         <term>Activate a unit immediately:</term>
    80         <listitem>
    81           <para><command>systemctl start</command> <replaceable>unit</replaceable></para>
    82         </listitem>
    83       </varlistentry>
    84 
    85       <varlistentry>
    86         <term>Stop a unit immediately:</term>
    87         <listitem>
    88           <para><command>systemctl stop </command><replaceable>unit</replaceable></para>
    89         </listitem>
    90       </varlistentry>
    91 
    92       <varlistentry>
    93         <term>Restart a unit:</term>
    94         <listitem>
    95           <para><command>systemctl restart </command><replaceable>unit</replaceable></para>
    96         </listitem>
    97       </varlistentry>
    98 
    99       <varlistentry>
    100         <term>Reload unit configuration:</term>
    101         <listitem>
    102           <para><command>systemctl reload </command><replaceable>unit</replaceable></para>
    103         </listitem>
    104       </varlistentry>
    105 
    106       <varlistentry>
    107         <term>Show status of a unit:</term>
    108         <listitem>
    109           <para><command>systemctl status </command><replaceable>unit</replaceable></para>
    110         </listitem>
    111       </varlistentry>
    112 
    113       <varlistentry>
    114         <term>Check if a unit is enabled or disabled:</term>
    115         <listitem>
    116           <para><command>systemctl is-enabled </command><replaceable>unit</replaceable></para>
    117         </listitem>
    118       </varlistentry>
    119 
    120       <varlistentry>
    121         <term>Enable a unit to start during boot:</term>
    122         <listitem>
    123           <para><command>systemctl enable </command><replaceable>unit</replaceable></para>
    124         </listitem>
    125       </varlistentry>
    126 
    127       <varlistentry>
    128         <term>Disable a unit to not start during boot:</term>
    129         <listitem>
    130           <para><command>systemctl disable </command><replaceable>unit</replaceable></para>
    131         </listitem>
    132       </varlistentry>
    133 
    134       <varlistentry>
    135         <term>Reload systemd and scan for new or changed units:</term>
    136         <listitem>
    137           <para><command>systemctl daemon-reload</command></para>
    138         </listitem>
    139       </varlistentry>
    140 
    141     </variablelist>
    142 
    143     <para>For more information regarding systemd, please refer to the systemd
    144     and related man-pages and
    145     <ulink url="https://fedoraproject.org/wiki/Systemd">Systemd at
    146     FedoraProject</ulink> for documentation, examples, features, and other
    147     information.</para>
    148 
    149   </sect2>
     125  <para>Feel free to modify the way the boot process works (after all,
     126  it is your own CLFS system). The files given here are an example of how
     127  it can be done.</para>
    150128
    151129</sect1>
Note: See TracChangeset for help on using the changeset viewer.