lfs-book/chapter07/usage.xml

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
  <!ENTITY % general-entities SYSTEM "../general.ent">
  %general-entities;
]>

<sect1 id="ch-scripts-usage">
  <?dbhtml filename="usage.html"?>

  <title>How Do These Bootscripts Work?</title>

  <indexterm zone="ch-scripts-usage">
    <primary sortas="a-Bootscripts">Bootscripts</primary>
    <secondary>usage</secondary>
  </indexterm>

  <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 LFS too. LFS 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>&lt;runlevel&gt;</replaceable></command>, where
  <replaceable>&lt;runlevel&gt;</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&mdash;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
  <parameter>start</parameter>, <parameter>stop</parameter>,
  <parameter>restart</parameter>, <parameter>reload</parameter>, and
  <parameter>status</parameter>. When a K link is encountered, the appropriate
  script is run with the <parameter>stop</parameter> argument. When an S link
  is encountered, the appropriate script is run with the
  <parameter>start</parameter> 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
  <parameter>stop</parameter> 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><parameter>start</parameter></term>
      <listitem>
        <para>The service is started.</para>
      </listitem>
    </varlistentry>

    <varlistentry>
      <term><parameter>stop</parameter></term>
      <listitem>
        <para>The service is stopped.</para>
      </listitem>
    </varlistentry>

    <varlistentry>
      <term><parameter>restart</parameter></term>
      <listitem>
        <para>The service is stopped and then started again.</para>
      </listitem>
    </varlistentry>

    <varlistentry>
      <term><parameter>reload</parameter></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><parameter>status</parameter></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 LFS system). The files given here are an example of how
  it can be done.</para>

</sect1>