mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-01-19 05:27:39 +00:00
a03cebdcff
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@10288 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
206 lines
8.3 KiB
XML
206 lines
8.3 KiB
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>
|
|
|
|
<sect2 id="conf-sysvinit" role="configuration">
|
|
<title>Configuring Sysvinit</title>
|
|
|
|
<indexterm zone="conf-sysvinit">
|
|
<primary sortas="a-Sysvinit">Sysvinit</primary>
|
|
<secondary>configuring</secondary>
|
|
</indexterm>
|
|
|
|
<indexterm zone="conf-sysvinit">
|
|
<primary sortas="e-/etc/inittab">/etc/inittab</primary>
|
|
</indexterm>
|
|
|
|
<para>During the kernel initialization, the first program that is run
|
|
is either specified on the command line or, by default
|
|
<command>init</command>. This program reads the initialization file
|
|
<filename>/etc/inittab</filename>. Create this file with:</para>
|
|
|
|
<screen><userinput>cat > /etc/inittab << "EOF"
|
|
<literal># Begin /etc/inittab
|
|
|
|
id:3:initdefault:
|
|
|
|
si::sysinit:/etc/rc.d/init.d/rc S
|
|
|
|
l0:0:wait:/etc/rc.d/init.d/rc 0
|
|
l1:S1:wait:/etc/rc.d/init.d/rc 1
|
|
l2:2:wait:/etc/rc.d/init.d/rc 2
|
|
l3:3:wait:/etc/rc.d/init.d/rc 3
|
|
l4:4:wait:/etc/rc.d/init.d/rc 4
|
|
l5:5:wait:/etc/rc.d/init.d/rc 5
|
|
l6:6:wait:/etc/rc.d/init.d/rc 6
|
|
|
|
ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
|
|
|
|
su:S016:once:/sbin/sulogin
|
|
|
|
1:2345:respawn:/sbin/agetty --noclear tty1 9600
|
|
2:2345:respawn:/sbin/agetty tty2 9600
|
|
3:2345:respawn:/sbin/agetty tty3 9600
|
|
4:2345:respawn:/sbin/agetty tty4 9600
|
|
5:2345:respawn:/sbin/agetty tty5 9600
|
|
6:2345:respawn:/sbin/agetty tty6 9600
|
|
|
|
# End /etc/inittab</literal>
|
|
EOF</userinput></screen>
|
|
|
|
<para>An explanation of this initialization file is in the man page for
|
|
<emphasis>inittab</emphasis>. For LFS, the key command that is run is
|
|
<command>rc</command>. The intialization file above will instruct
|
|
<command>rc</command> to run all the scripts starting with an S in the
|
|
<filename class="directory">/etc/rc.d/rcS.d</filename> directory
|
|
followed by all the scripts starting with an S in the <filename
|
|
class="directory">/etc/rc.d/rc?.d</filename> directory where the question
|
|
mark is specified by the initdefault value.</para>
|
|
|
|
<para>As a convenience, the <command>rc</command> script reads a library of
|
|
functions in <filename class="directory">/lib/lsb/init-functions</filename>.
|
|
This library also reads an optional configuration file,
|
|
<filename>/etc/sysconfig/rc.site</filename>. Any of the system
|
|
configuration file parameters described in subsequent sections can be
|
|
alternatively placed in this file allowing consolidation of all system
|
|
parameters in this one file.</para>
|
|
|
|
<para>As a debugging convenience, the functions script also logs all output
|
|
to <filename>/run/var/bootlog</filename>. Since the <filename
|
|
class="directory">/run</filename> directory is a tmpfs, this file is not
|
|
persistent across boots, however it is appended to the more permanent file
|
|
<filename>/var/log/boot.log</filename> at the end of the boot process.</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2 id="init-levels" >
|
|
<title>Changing Run Levels</title>
|
|
|
|
<para>Changing run-levels is done with <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. K links and S 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>
|
|
|
|
</sect2>
|
|
|
|
</sect1>
|