- Timestamp:
- 07/02/2005 05:16:45 PM (19 years ago)
- Branches:
- 6.1, 6.1.1
- Children:
- b8a3fb2
- Parents:
- 464fa64f
- Location:
- chapter07
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter07/bootscripts.xml
r464fa64f rb568bbaf 51 51 <term><command>checkfs</command></term> 52 52 <listitem> 53 <para>Checks the file systems before they are mounted (with the exception of journal54 and network based file systems)</para>53 <para>Checks the integrity of the file systems before they are mounted (with the 54 exception of journal and network based file systems)</para> 55 55 <indexterm zone="ch-scripts-bootscripts checkfs-bootscripts"><primary sortas="d-checkfs">checkfs</primary></indexterm> 56 56 </listitem> … … 72 72 <term><command>console</command></term> 73 73 <listitem> 74 <para>Loads the keymap table specified as proper for the keyboard75 layout; it alsosets the screen font</para>74 <para>Loads the correct keymap table for the desired keyboard layout; it also 75 sets the screen font</para> 76 76 <indexterm zone="ch-scripts-bootscripts console-bootscripts"><primary sortas="d-console">console</primary></indexterm> 77 77 </listitem> … … 81 81 <term><command>functions</command></term> 82 82 <listitem> 83 <para>Contains functions shared among different scripts, such as error84 and status checking</para>83 <para>Contains common functions that are used by several bootscripts, such as 84 error and status checking</para> 85 85 <indexterm zone="ch-scripts-bootscripts functions-bootscripts"><primary sortas="d-functions">functions</primary></indexterm> 86 86 </listitem> … … 98 98 <term><command>hotplug</command></term> 99 99 <listitem> 100 <para>Load modules for system devices</para>100 <para>Loads modules for system devices</para> 101 101 <indexterm zone="ch-scripts-bootscripts hotplug-bootscripts"><primary sortas="d-hotplug">hotplug</primary></indexterm> 102 102 </listitem> … … 106 106 <term><command>ifdown</command></term> 107 107 <listitem> 108 <para>Assists the network script with network devices</para>108 <para>Assists the network script with stopping network devices</para> 109 109 <indexterm zone="ch-scripts-bootscripts ifdown-bootscripts"><primary sortas="d-ifdown">ifdown</primary></indexterm> 110 110 </listitem> … … 114 114 <term><command>ifup</command></term> 115 115 <listitem> 116 <para>Assists the network script with network devices</para>116 <para>Assists the network script with starting network devices</para> 117 117 <indexterm zone="ch-scripts-bootscripts ifup-bootscripts"><primary sortas="d-ifup">ifup</primary></indexterm> 118 118 </listitem> … … 139 139 <term><command>mountkernfs</command></term> 140 140 <listitem> 141 <para> Is used to mount kernel-provided file systems, such as142 <systemitemclass="filesystem">proc</systemitem></para>141 <para>Mounts virtual kernel file systems, such as <systemitem 142 class="filesystem">proc</systemitem></para> 143 143 <indexterm zone="ch-scripts-bootscripts mountkernfs-bootscripts"><primary sortas="d-mountkernfs">mountkernfs</primary></indexterm> 144 144 </listitem> … … 157 157 <term><command>rc</command></term> 158 158 <listitem> 159 <para>The master run-level control script; it is responsible for 160 running all other scripts one-by-one, in a sequence determined by 161 the name of thesymbolic links being processed</para>159 <para>The master run-level control script; it is responsible for running all the 160 other bootscripts one-by-one, in a sequence determined by the name of the 161 symbolic links being processed</para> 162 162 <indexterm zone="ch-scripts-bootscripts rc-bootscripts"><primary sortas="d-rc">rc</primary></indexterm> 163 163 </listitem> … … 227 227 <term><command>udev</command></term> 228 228 <listitem> 229 <para> Sets up udev and create the device nodes in <filename230 class="directory">/dev</filename></para>229 <para>Prepares the <filename class="directory">/dev</filename> directory and 230 starts Udev</para> 231 231 <indexterm zone="ch-scripts-bootscripts udev-bootscripts"><primary sortas="d-udev">udev</primary></indexterm> 232 232 </listitem> -
chapter07/console.xml
r464fa64f rb568bbaf 12 12 <secondary>configuring</secondary></indexterm> 13 13 14 <para>This section discusses how to configure the 15 <command>console</command> initscript that sets up the keyboard map 16 and the console font. If non-ASCII characters (British pound and Euro 17 character are examples of non-ASCII characters) will not be used and18 the keyboard is a U.S. one, skip this section. Without the 19 configuration file, the console initscript willdo nothing.</para>14 <para>This section discusses how to configure the <command>console</command> 15 bootscript that sets up the keyboard map and the console font. If non-ASCII 16 characters (British pound and Euro character are examples of non-ASCII 17 characters) will not be used and the keyboard is a U.S. one, skip this section. 18 Without the configuration file, the <command>console</command> bootscript will 19 do nothing.</para> 20 20 21 <para>The <command>console</command> script uses the22 <filename>/etc/sysconfig/console</filename> as a configuration file.23 Decide which keymap and screen font will be used. The24 language-specific HOWTO can help with this. A pre-made 25 <filename>/etc/sysconfig/console</filename> file with known settings 26 for several countries was installed with the LFS-Bootscripts package, 27 so the relevant section can be uncommented if the country is 28 s upported. If still in doubt, look in the <filename29 class="directory">/usr/share/kbd</filename> directory for valid30 keymaps and screen fonts. 31 <command>setfont</command> manual pages 32 and determine the correct arguments for these programs. Once decided, 33 c reate the configuration file with the following command:</para>21 <para>The <command>console</command> script reads the 22 <filename>/etc/sysconfig/console</filename> file for configuration information. 23 Decide which keymap and screen font will be used. Various language-specific 24 HOWTO's can also help with this (see <ulink 25 url="http://www.tldp.org/HOWTO/HOWTO-INDEX/other-lang.html"/>. A pre-made 26 <filename>/etc/sysconfig/console</filename> file with known settings for several 27 countries was installed with the LFS-Bootscripts package, so the relevant 28 section can be uncommented if the country is supported. If still in doubt, look 29 in the <filename class="directory">/usr/share/kbd</filename> directory for valid 30 keymaps and screen fonts. Read the <command>loadkeys</command> and 31 <command>setfont</command> manual pages and determine the correct arguments for 32 these programs. Once decided, create the configuration file with the following 33 command:</para> 34 34 35 35 <screen><userinput>cat >/etc/sysconfig/console <<"EOF" -
chapter07/hostname.xml
r464fa64f rb568bbaf 12 12 <secondary>configuring</secondary></indexterm> 13 13 14 <para>Part of the <command>localnet</command> script is setting up the system's15 hostname. This needs to be configured in the14 <para>Part of the job of the <command>localnet</command> script is setting the 15 system's hostname. This needs to be configured in the 16 16 <filename>/etc/sysconfig/network</filename> file.</para> 17 17 18 <para>Create the <filename>/etc/sysconfig/network</filename> file and enter a hostname by19 running:</para>18 <para>Create the <filename>/etc/sysconfig/network</filename> file and enter a 19 hostname by running:</para> 20 20 21 21 <screen><userinput>echo "HOSTNAME=<replaceable>[lfs]</replaceable>" > /etc/sysconfig/network</userinput></screen> 22 22 23 <para><replaceable>[lfs]</replaceable> needs to be replaced with the 24 name the computer is to be called. Do not enter the Fully Qualified 25 Domain Name (FQDN) here. That information will be put in the 26 <filename>/etc/hosts</filename> file later.</para>23 <para><replaceable>[lfs]</replaceable> needs to be replaced with the name given 24 to the computer. Do not enter the Fully Qualified Domain Name (FQDN) here. That 25 information will be put in the <filename>/etc/hosts</filename> file in the next 26 section.</para> 27 27 28 28 </sect1> -
chapter07/network.xml
r464fa64f rb568bbaf 48 48 EOF</userinput></screen> 49 49 50 <para>The values of these variables must be changed in every file to 51 match the proper setup. If the <envar>ONBOOT</envar> variable is 52 set to <quote>yes</quote> the network script will bring up the 53 Network Interface Card (NIC) during booting of the system. If set 54 to anything but <quote>yes</quote> the NIC will be ignored by the 55 network script and not brought up.</para> 50 <para>The values of these variables must be changed in every file to match the 51 proper setup. If the <envar>ONBOOT</envar> variable is set to <quote>yes</quote> 52 the network script will bring up the Network Interface Card (NIC) during booting 53 of the system. If set to anything but <quote>yes</quote> the NIC will be ignored 54 by the network script and not be brought up.</para> 56 55 57 <para>The <envar>SERVICE</envar> variable defines the method of obtaining the IP58 address. The LFS-Bootscripts package has a modular IP assignment format, and 59 creating additional files in the <filename56 <para>The <envar>SERVICE</envar> variable defines the method used in obtaining 57 the IP address. The LFS-Bootscripts package has a modular IP assignment format, 58 and creating additional files in the <filename 60 59 class="directory">/etc/sysconfig/network-devices/services</filename> directory 61 60 allows other IP assignment methods. This is commonly used for Dynamic Host … … 66 65 the variable entirely.</para> 67 66 68 <para>The <envar>PREFIX</envar> variable needs to contain the 69 number of bits used in the subnet. Each octet in an IP address is 8 70 bits. If the subnet's netmask is 255.255.255.0, then it is using the 71 first three octets (24 bits) to specify the network number. If the 72 netmask is 255.255.255.240, it would be using the first 28 bits. 73 Prefixes longer than 24 bits are commonly used by DSL and cable-based 74 Internet Service Providers (ISPs). In this example (PREFIX=24), the netmask 75 is 255.255.255.0. Adjust according to thespecific subnet.</para>67 <para>The <envar>PREFIX</envar> variable needs to contain the number of bits 68 used in the subnet. Each octet in an IP address is 8 bits. If the subnet's 69 netmask is 255.255.255.0, then it is using the first three octets (24 bits) to 70 specify the network number. If the netmask is 255.255.255.240, it would be using 71 the first 28 bits. Prefixes longer than 24 bits are commonly used by DSL and 72 cable-based Internet Service Providers (ISPs). In this example (PREFIX=24), the 73 netmask is 255.255.255.0. Adjust the <envar>PREFIX</envar> variable according to 74 your specific subnet.</para> 76 75 77 76 <beginpage/> -
chapter07/profile.xml
r464fa64f rb568bbaf 42 42 <listitem><para>The output of programs translated into the native 43 43 language</para></listitem> 44 <listitem><para>Correct classification of characters into letters, 45 digits and other classes. This is necessary for Bash to properly 46 accept non-ASCII characters in command lines in non-English 47 locales</para></listitem> 44 <listitem><para>Correct classification of characters into letters, digits and 45 other classes. This is necessary for <command>bash</command> to properly accept 46 non-ASCII characters in command lines in non-English locales</para></listitem> 48 47 <listitem><para>The correct alphabetical sorting order for the 49 48 country</para></listitem> -
chapter07/setclock.xml
r464fa64f rb568bbaf 12 12 <secondary>configuring</secondary></indexterm> 13 13 14 <para>The <command>setclock</command> script reads the time from the hardware clock,15 also known as the BIOS or the Complementary Metal Oxide Semiconductor16 (CMOS) clock. If the hardware clock is set to UTC, this script will convert the hardware clock's time to17 the local time using the <filename>/etc/localtime</filename> file18 (which tells the <command>hwclock</command> program which timezonethe19 user is in). There is no way to20 detect whether or not the hardware clock is set to UTC time, so this21 needs to be manually configured.</para>14 <para>The <command>setclock</command> script reads the time from the hardware 15 clock, also known as the BIOS or the Complementary Metal Oxide Semiconductor 16 (CMOS) clock. If the hardware clock is set to UTC, this script will convert the 17 hardware clock's time to the local time using the 18 <filename>/etc/localtime</filename> file (which tells the 19 <command>hwclock</command> program which timezone the user is in). There is no 20 way to detect whether or not the hardware clock is set to UTC time, so this 21 needs to be configured manually.</para> 22 22 23 <para>If you cannot remember whether or not the hardware 24 clock is set to UTC time, find out by running 25 the <userinput>hwclock --localtime --show</userinput> command. This will tell 26 what the current time is according to the hardware clock. If this time 27 matches whatever your watch says, then the hardware clock is set to 28 local time. If the output from <command>hwclock</command> is not local 29 time, chances are it is set to UTC time. Verify this by adding or 30 subtracting the proper amount of hours for the timezone to this 31 <command>hwclock</command> time. For example, if you live in the MST 23 <para>If you cannot remember whether or not the hardware clock is set to UTC 24 time, find out by running the <userinput>hwclock --localtime --show</userinput> 25 command. This will display what the current time is according to the hardware 26 clock. If this time matches whatever your watch says, then the hardware clock is 27 set to local time. If the output from <command>hwclock</command> is not local 28 time, chances are it is set to UTC time. Verify this by adding or subtracting 29 the proper amount of hours for the timezone to the time shown by 30 <command>hwclock</command>. For example, if you are currently in the MST 32 31 timezone, which is also known as GMT -0700, add seven hours to the local 33 time. Then, account for Daylight Savings Time, which requires 34 subtracting an hour (or only add six in the first place) during the summer 35 months.</para> 32 time.</para> 36 33 37 34 <para>Change the value of the <envar>UTC</envar> variable below -
chapter07/udev.xml
r464fa64f rb568bbaf 13 13 14 14 <para>In <xref linkend="chapter-building-system"/>, we installed the Udev 15 package. 15 package. Before we go into the details regarding how this works, 16 16 a brief history of previous methods of handling devices is in 17 17 order.</para> 18 18 19 <para>Linux systems in general traditionally use a static device 20 creation method, whereby a great many device nodes are created under 21 <filename class="directory">/dev</filename> (sometimes literally 22 thousands of nodes), regardless of whether the corresponding hardware 23 devices actually exist. This is typically done via a 24 <command>MAKEDEV</command> script, which contains a number of 25 calls to the <command>mknod</command> program with the relevant major and minor device 26 numbers for every possible device that might exist in the world. Using 27 the udev method, only those devices which are detected by the kernel 28 get device nodes created for them. Because these device nodes will be 29 created each time the system boots, they will be stored on a 30 <systemitem class="filesystem">tmpfs</systemitem> (a file system that 31 resides entirely in memory and does not take up any disk space). 32 Device nodes do not require much disk space, so the memory that is 33 used is negligible.</para> 19 <para>Linux systems in general traditionally use a static device creation 20 method, whereby a great many device nodes are created under <filename 21 class="directory">/dev</filename> (sometimes literally thousands of nodes), 22 regardless of whether the corresponding hardware devices actually exist. This is 23 typically done via a <command>MAKEDEV</command> script, which contains a number 24 of calls to the <command>mknod</command> program with the relevant major and 25 minor device numbers for every possible device that might exist in the world. 26 Using the Udev method, only those devices which are detected by the kernel get 27 device nodes created for them. Because these device nodes will be created each 28 time the system boots, they will be stored on a <systemitem 29 class="filesystem">tmpfs</systemitem> file system (a virtual file system that 30 resides entirely in system memory). Device nodes do not require much space, so 31 the memory that is used is negligible.</para> 34 32 35 33 <sect2> … … 55 53 as deprecated due to a lack of recent maintenance.</para> 56 54 57 <para>With the development of the unstable 2.5 kernel tree, later 58 released as the 2.6 series of stable kernels, a new virtual filesystem 59 called <systemitem class="filesystem">sysfs</systemitem> came to be. 60 The job of <systemitem class="filesystem">sysfs</systemitem> is to 61 export a view of the system's structure to userspace processes. With 62 this userspace visible representation, the possibility of seeing a 63 userspace replacement for <systemitem 64 class="filesystem">devfs</systemitem> became much more 55 <para>With the development of the unstable 2.5 kernel tree, later released as 56 the 2.6 series of stable kernels, a new virtual filesystem called <systemitem 57 class="filesystem">sysfs</systemitem> came to be. The job of <systemitem 58 class="filesystem">sysfs</systemitem> is to export a view of the system's 59 hardrware configuration to userspace processes. With this userspace-visible 60 representation, the possibility of seeing a userspace replacement for 61 <systemitem class="filesystem">devfs</systemitem> became much more 65 62 realistic.</para> 63 66 64 </sect2> 67 65 … … 69 67 <title>Udev Implementation</title> 70 68 71 <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem 72 was mentioned briefly above. One may wonder how <systemitem 73 class="filesystem">sysfs</systemitem> knows about the devices present 74 on a system and what device numbers should be used. Drivers that 75 have been compiled into the kernel directly register their objects 76 with <systemitem class="filesystem">sysfs</systemitem> as they are 77 detected by the kernel. For drivers compiled as modules, this will 78 happen when the module is loaded. Once the <systemitem 79 class="filesystem">sysfs</systemitem> filesystem is mounted (on 80 <filename class="directory">/sys</filename>), data which the 69 <para>The <systemitem class="filesystem">sysfs</systemitem> filesystem was 70 mentioned briefly above. One may wonder how <systemitem 71 class="filesystem">sysfs</systemitem> knows about the devices present on a 72 system and what device numbers should be used for them. Drivers that have been 73 compiled into the kernel directly register their objects with <systemitem 74 class="filesystem">sysfs</systemitem> as they are detected by the kernel. For 75 drivers compiled as modules, this registration will happen when the module is 76 loaded. Once the <systemitem class="filesystem">sysfs</systemitem> filesystem is 77 mounted (on <filename class="directory">/sys</filename>), data which the 81 78 built-in drivers registered with <systemitem 82 class="filesystem">sysfs</systemitem> are available to userspace 83 processes andto <command>udev</command> for device node creation.</para>79 class="filesystem">sysfs</systemitem> are available to userspace processes and 80 to <command>udev</command> for device node creation.</para> 84 81 85 82 <para>The <command>S10udev</command> initscript takes care of creating these 86 device nodes when Linux is booted. This script starts withregistering87 <command>/sbin/udevsend</command> as a hotplug event handler. 88 (discussed below) should not begenerated during this stage, but89 <command>udev</command> is registered just in case they do occur. 83 device nodes when Linux is booted. This script starts by registering 84 <command>/sbin/udevsend</command> as a hotplug event handler. Hotplug events 85 (discussed below) are not usually generated during this stage, but 86 <command>udev</command> is registered just in case they do occur. The 90 87 <command>udevstart</command> program then walks through the <systemitem 91 88 class="filesystem">/sys</systemitem> filesystem and creates devices under 92 <filename class="directory">/dev</filename> that match the descriptions. 89 <filename class="directory">/dev</filename> that match the descriptions. For 93 90 example, <filename>/sys/class/tty/vcs/dev</filename> contains the string 94 91 <quote>7:0</quote> This string is used by <command>udevstart</command> to create 95 92 <filename>/dev/vcs</filename> with major number <emphasis>7</emphasis> and minor 96 <emphasis>0</emphasis>. 93 <emphasis>0</emphasis>. The names and permissions of the nodes created under 97 94 the <filename class="directory">/dev</filename> directory are configured 98 95 according to the rules specified in the files within the <filename … … 102 99 <emphasis>660</emphasis> and ownership to <emphasis>root:root</emphasis>.</para> 103 100 104 <para>Once the above stage is complete, all devices that were already 105 present and have compiled-in drivers will be available for use. What 106 about those devices that have modular drivers?</para>101 <para>Once the above stage is complete, all devices that were already present 102 and have compiled-in drivers will be available for use. This leads us to the 103 devices that have modular drivers.</para> 107 104 108 105 <para>Earlier, we mentioned the concept of a <quote>hotplug event 109 handler.</quote> When a new device connection is detected by the 110 kernel, the kernel will generate a hotplug event and look at the file 111 <filename>/proc/sys/kernel/hotplug</filename> to find out the 112 userspace program that handles the device's connection. The 113 <command>udev</command> initscript registered <command>udevsend</command> 114 as this handler. When these hotplug events are generated, the kernel 115 will tell <command>udev</command> to check the <filename 116 class="directory">/sys</filename> filesystem for the information 106 handler.</quote> When a new device connection is detected by the kernel, the 107 kernel will generate a hotplug event and look at the file 108 <filename>/proc/sys/kernel/hotplug</filename> to determine the userspace program 109 that handles the device's connection. The <command>udev</command> bootscript 110 registered <command>udevsend</command> as this handler. When these hotplug 111 events are generated, the kernel will tell <command>udev</command> to check the 112 <filename class="directory">/sys</filename> filesystem for the information 117 113 pertaining to this new device and create the <filename 118 114 class="directory">/dev</filename> entry for it.</para> 119 115 120 <para>This brings us to one problem that exists with 121 <command>udev</command>, and likewise with <systemitem 122 class="filesystem">devfs</systemitem> before it. It is commonly 123 referred to as the <quote>chicken and egg</quote> problem. Most Linux 124 distributions handle loading modules via entries in 125 <filename>/etc/modules.conf</filename>. Access to a device node causes 126 the appropriate kernel module to load. With <command>udev</command>, 127 this method will not work because the device node does not exist until 128 the module is loaded. To solve this, the 129 <command>S05modules</command> bootscript was added to the 116 <para>This brings us to one problem that exists with <command>udev</command>, 117 and likewise with <systemitem class="filesystem">devfs</systemitem> before it. 118 It is commonly referred to as the <quote>chicken and egg</quote> problem. Most 119 Linux distributions handle loading modules via entries in 120 <filename>/etc/modules.conf</filename>. Access to a device node causes the 121 appropriate kernel module to load. With <command>udev</command>, this method 122 will not work because the device node does not exist until the module is loaded. 123 To solve this, the <command>S05modules</command> bootscript was added to the 130 124 LFS-Bootscripts package, along with the 131 <filename>/etc/sysconfig/modules</filename> file. By 132 adding module 133 names to the <filename>modules</filename> file, these modules will be 134 loaded when the computer is starting up. This allows 135 <command>udev</command> to detect the devices and create the 136 appropriate device nodes.</para> 125 <filename>/etc/sysconfig/modules</filename> file. By adding module names to the 126 <filename>modules</filename> file, these modules will be loaded when the 127 computer is starts up. This allows <command>udev</command> to detect the devices 128 and create the appropriate device nodes.</para> 137 129 138 130 <para>Note that on slower machines or for drivers that create a lot … … 168 160 class="filesystem">sysfs</systemitem>.</para> 169 161 170 <para>This is most common with third party drivers from outside the 171 kernel tree. These drivers will not end up having their device nodes 172 created. Use the 173 <filename>/etc/sysconfig/createfiles</filename> configuration file to 174 manually create the devices. Consult the 175 <filename>devices.txt</filename> file inside the kernel documentation 176 or the documentation for that driver to find the proper major/minor 177 numbers.</para> 162 <para>This is most common with third party drivers from outside the kernel tree. 163 Udev will be unable to automatically create device nodes for such drivers. Use 164 the <filename>/etc/sysconfig/createfiles</filename> configuration file to 165 manually create the devices. Consult the <filename>devices.txt</filename> file 166 inside the kernel documentation or the documentation for that driver to find the 167 proper major/minor numbers.</para> 178 168 179 169 <para>2) A non-hardware device is required. This is most common with -
chapter07/usage.xml
r464fa64f rb568bbaf 12 12 <secondary>usage</secondary></indexterm> 13 13 14 <para>Linux uses a special booting facility named SysVinit that is 15 based on a concept of <emphasis>run-levels</emphasis>. It can be quite 16 different from one system to another, so it cannot be assumed that 17 because things worked in <insert distro name>, they should work 18 the same in LFS too. LFS has its own way of doing things, but it 19 respects generally accepted standards.</para> 14 <para>Linux uses a special booting facility named SysVinit that is based on a 15 concept of <emphasis>run-levels</emphasis>. It can be quite different from one 16 system to another, so it cannot be assumed that because things worked in one 17 particular Linux distribution, they should work the same in LFS too. LFS has its 18 own way of doing things, but it respects generally accepted standards.</para> 20 19 21 <para>SysVinit (which will be referred to as <quote>init</quote> from 22 now on) works using a run-levels scheme. There are seven (from 0 to 6) 23 run-levels (actually, there are more run-levels, but they are for 24 special cases and are generally not used. The init man page describes 25 those details), and each one of those corresponds to the actions the 26 computer is supposed to perform when it starts up. The default 27 run-level is 3. Here are the descriptions of the different run-levels 28 as they are implemented:</para> 20 <para>SysVinit (which will be referred to as <quote>init</quote> from now on) 21 works using a run-levels scheme. There are seven (from 0 to 6) run-levels 22 (actually, there are more run-levels, but they are for special cases and are 23 generally not used. The init manual page describes those details), and each one 24 of those corresponds to the actions the computer is supposed to perform when it 25 starts up. The default run-level is 3. Here are the descriptions of the 26 different run-levels as they are implemented:</para> 29 27 30 28 <literallayout>0: halt the computer … … 38 36 <para>The command used to change run-levels is <command>init 39 37 <replaceable>[runlevel]</replaceable></command>, where 40 <replaceable>[runlevel]</replaceable> is the target run-level. For 41 example, to reboot the computer, a user would issue the <command>init 42 6</command> command. The <command>reboot</command> command is an 43 alias for it, as is the <command>halt</command> command an alias for 44 <command>init 0</command>.</para>38 <replaceable>[runlevel]</replaceable> is the target run-level. For example, to 39 reboot the computer, a user could issue the <command>init 6</command> command, 40 which is an alias for the <command>reboot</command> command. Likewise, 41 <command>init 0</command> is an alias for the <command>halt</command> 42 command.</para> 45 43 46 44 <para>There are a number of directories under <filename 47 45 class="directory">/etc/rc.d</filename> that look like <filename 48 class="directory">rc?.d</filename> (where ? is the number of the 49 run-level) and <filename class="directory">rcsysinit.d</filename>, all 50 containing a number of symbolic links. Some begin with a 51 <emphasis>K</emphasis>, the others begin with an 52 <emphasis>S</emphasis>, and all of them have two numbers following the 53 initial letter. The K means to stop (kill) a service and the S means 54 to start a service. The numbers determine the order in which the 55 scripts are run, from 00 to 99—the lower the number the earlier it 56 gets executed. When init switches to another run-level, the 57 appropriate services get killed and others get started.</para> 46 class="directory">rc?.d</filename> (where ? is the number of the run-level) and 47 <filename class="directory">rcsysinit.d</filename>, all containing a number of 48 symbolic links. Some begin with a <emphasis>K</emphasis>, the others begin with 49 an <emphasis>S</emphasis>, and all of them have two numbers following the 50 initial letter. The K means to stop (kill) a service and the S means to start a 51 service. The numbers determine the order in which the scripts are run, from 00 52 to 99—the lower the number the earlier it gets executed. When 53 <command>init</command> switches to another run-level, the appropriate services 54 are either started or stopped, depending on the runlevel chosen.</para> 58 55 59 56 <para>The real scripts are in <filename
Note:
See TracChangeset
for help on using the changeset viewer.