Red Hat Linux 6.2: The Official Red Hat Linux Reference Guide | ||
---|---|---|
Prev | Chapter 2. System Administration | Next |
This section contains information on what happens when you boot or shut down your Red Hat Linux system.
When a computer is booted, the processor looks at the end of the system memory for the BIOS (Basic Input/Output System) and runs it. The BIOS program is written into read-only permanent memory, and is always ready to go. The BIOS provides the lowest level interface to peripheral devices and controls the first step of the boot process.
The BIOS tests the system, looks for and checks peripherals and then looks for a drive to boot from. Usually, it checks the floppy drive (or CD-ROM drive on many newer systems), if present, and then it looks on the hard drive. On the hard drive, the BIOS looks for a Master Boot Record (MBR) starting at the first sector on the first hard drive and starts the MBR running.
The MBR looks for the first active partition and reads the partition's boot record. The boot record contains instructions on how to load the boot loader, LILO (LInux LOader). The MBR then loads LILO and LILO takes over the process.
LILO reads the file /etc/lilo.conf, which spells out which operating system(s) to configure or which kernel to start and where to install itself (for example, /dev/hda for your hard drive). LILO displays a LILO: prompt on the screen and waits for a preset period of time (also set in the lilo.conf file) for input from the user. If your lilo.conf is set to give LILO a choice of operating systems, at this time you could type in the label for whichever OS you wanted to boot.
After waiting for a set period of time (five seconds is common), LILO proceeds to boot whichever operating system appears first in the lilo.conf file.
If LILO is booting Linux, it first boots the kernel, which is a vmlinuz file (plus a version number, for example, vmlinuz-2.2.15-xx) located in the /boot directory. Then the kernel takes over.
The kernel looks in several different places for init (/sbin is a common location) and runs the first one it finds. Init takes over.
Init starts (and becomes the parent or grandparent of) all of the processes which make up your Linux system. First, it runs /etc/rc.d/rc.sysinit, which sets your path, sets up networking if necessary, starts swapping, checks the filesystems, and so on. Basically, rc.sysinit is taking care of everything that your system needs to have done at system initialization. For example, on a networked system rc.sysinit uses the information in the /etc/sysconfig/network and /etc/sysconfig/clock files to initialize network processes and the clock. Itmay also run rc.serial, if you have serial port processes that need to be initialized.
Init looks at and implements the /etc/inittab file. The /etc/inittab file describes how the system should be set up in each runlevel and sets the default runlevel. This file states that /etc/rc.d/rc and /sbin/update should be run whenever a runlevel starts.
The /sbin/update file flushes dirty buffers back to disk.
Whenever the runlevel changes, /etc/rc.d/rc starts and stops services. First, rc sets the source function library for the system (commonly /etc/rc.d/init.d/functions), which spells out how to start/kill a program and how to find out the PID of a program. The rc file then finds out the current and the previous runlevel and tells linuxconf the appropriate runlevel.
The rc file starts all of the background processes necessary for the system to run, and looks for an rc directory for that runlevel (/etc/rc.d/rc<x>.d, where the <x> is numbered 0-6). rc kills all of the kill scripts (their file name starts with a K) in /rc.d/. Then it initializes all of the start scripts (their file names start with an S) in the appropriate runlevel directory (so that all services and applications are started correctly).
For example, for runlevel 5, rc looks into the /etc/rc.d/rc5.d directory and finds that it needs to kill rusersd, rwalld, rwhod, mcserv, mars-nwe, apmd, and pcmcia. In the bloody aftermath, rc looks into the same directory and finds start scripts for kmod, network, nfsfs, randomc, syslog, atd, crond, portmap, snmpd, inet, xntpd, lpd, nfs.rpmsave, dhcpd, ypbind, autofs, keytable, sendmail, gpm, sound, and smb.rpmsave. And life begins anew.
The /etc/inittab file forks a getty process for each virtual console (login prompts) for each runlevel (runlevels 2-5 get all six; runlevel 1, which is single user mode, only gets one console; runlevels 0 and 6 get no virtual consoles). /etc/inittab also states that gdm, the X logon manager, should start in runlevel 5.
Also, /etc/inittab describes how the system
should handle translating
At this point, you should be looking at a login prompt. All that, and it only took a few seconds.
Next, we'll discuss information on the files in /etc/sysconfig.
The following information outlines the various files in /etc/sysconfig, their function, and their contents.
The following files are normally found in /etc/sysconfig:
/etc/sysconfig/clock
/etc/sysconfig/hwconf (this should be ignored for editing)
/etc/sysconfig/mouse
/etc/sysconfig/sendmail
/etc/sysconfig/apmd
/etc/sysconfig/init
/etc/sysconfig/keyboard
/etc/sysconfig/network
/etc/sysconfig/pcmica
/etc/sysconfig/soundcard (which is written by sndconfig)
Let's take a look at each one.
The /etc/sysconfig/clock file controls the interpretation of values read from the system clock. Earlier releases of Red Hat Linux used the following values (which are deprecated):
CLOCKMODE=mode, where mode is one of the following:
GMT -- indicates that the clock is set to UTC.
ARC -- on Alpha only indicates the ARC console's 42-year time offset is in effect.
Currently, the correct values are:
UTC=boolean, where boolean is the following:
true -- indicates that the clock is set to UTC. Any other value indicates that it is set to local time.
ARC=boolean, where boolean is the following:
true -- (for Alpha-based systems only) Indicates the ARC console's 42-year time offset is in effect. Any other value indicates that the normal UNIX epoch is assumed.
ZONE="filename" -- indicates the zonefile under /user/share/zoneinfo that /etc/localtime is a copy of, for example:
ZONE="US/Eastern" |
The /etc/sysconfig/hwconf file lists all the hardware that kudzu detected on your system, as well as the drivers used, vendor ID and device ID information. It is not meant to be edited. If you do edit it, devices could suddenly show up as being added or removed.
The /etc/sysconfig/mouse file is used to specify information about the available mouse. The following values may be used:
MOUSETYPE=type, where type is one of the following:
microsoft -- A Microsoft mouse.
mouseman -- A MouseMan mouse.
mousesystems -- A Mouse Systems mouse.
ps/2 -- A PS/2 mouse.
msbm -- A Microsoft bus mouse.
logibm -- A Logitech bus mouse.
atibm -- An ATI bus mouse.
logitech -- A Logitech mouse.
mmseries -- An older MouseMan mouse.
mmhittab -- An mmhittab mouse.
XEMU3=emulation, where emulation is one of the following:
yes -- Three mouse buttons should be emulated.
no -- The mouse already has three buttons.
In addition, /dev/mouse is a symlink that points to the actual mouse device.
The /etc/sysconfig/sendmail allows messages to be sent to one or more recipients, routing the message over whatever networks are necessary. The file sets the default values for the sendmail program to run. Its default values are to run as a background daemon, and to check its queue once an hour in case something has backed up.
The following values may be used:
DAEMON=answer, where answer is one of the following:
yes -- Sendmail should be configured. yes implies -bd.
no -- Sendmail should not be configured.
QUEUE=1h which is given to sendmail as -q$QUEUE. The -q option is not given to sendmail if /etc/sysconfig/sendmail exists and QUEUE is empty or undefined.
The /etc/sysconfig/apmd is used by apmd, as a configuration for what things to start/stop/change on suspend or resume. It is set up to turn on or off apmd during startup, depending on whether your hardware supports Advanced Power Management (apm), or if you choose not to use it.
The /etc/sysconfig/init file controls how the system will look during bootup.
The following values may be used:
BOOTUP=<some bootup mode>, where <some bootup mode> is one of the following:
BOOTUP=color means new (as of Red Hat Linux 6.0) boot display.
BOOTUP=verbose means old style display.
Anything else means new display, but without ANSI-formatting.
LOGLEVEL=<a number>, where <a number> sets the initial console logging level for the kernel. The default is 7; 8 means everything (including debugging); 1 means nothing except kernel panics. syslogd will override this once it starts.
RES_COL=<a number>, where <a number> is a column of the screen to start status labels at. Defaults to 60.
MOVE_TO_COL=<a command>, where <a command> moves the cursor to $RES_COL. Defaults to ANSI sequences output by echo -e.
SETCOLOR_SUCCESS=<a command>, where <a command> sets the color to a color indicating success. Defaults to ANSI sequences output by echo -e, setting the color to green.
SETCOLOR_FAILURE=<a command>, where <a command> sets the color to a color indicating failure. Defaults to ANSI sequences output by echo -e, setting the color to red.
SETCOLOR_WARNING=<a command>, where <a command> sets the color to a color indicating warning. Defaults to ANSI sequences output by echo -e, setting the color to yellow.
SETCOLOR_NORMAL=<a command>, where <a command> sets the color to 'normal'. Defaults to ANSI sequences output by echo -e.
MAGIC_SYSRQ=an answer, where an answer is one of the following:
yes -- Enables the magic sysrq key.
no -- Disables the magic sysrq key,
and
PROMPT=an answer, where an answer is one of the following:
yes -- Enables the key check for interactive mode.
no -- Disables the key check for interactive mode.
The /etc/sysconfig/keyboard file controls the behavior of the keyboard. The following values may be used:
KEYTABLE=file, where file is the name of a keytable file. For example: KEYTABLE="/usr/lib/kbd/keytables/us.map"
KEYBOARD=sun|pc, which is used on SPARCs only. sun means a Sun keyboard is attached on /dev/kbd, pc means a PS/2 keyboard is on a PS/2 port.
The /etc/sysconfig/network file is used to specify information about the desired network configuration. The following values may be used:
NETWORKING=answer, where answer is one of the following:
yes -- Networking should be configured.
no -- Networking should not be configured.
HOSTNAME=hostname, where hostname should be the FQDN (Fully Qualified Domain Name), but can be whatever hostname you want.
Please Note | |
---|---|
For compatibility with older software that people might install (such as trn), the /etc/HOSTNAME file should contain the same value as here. |
FORWARD_IPV4=answer, where answer is one of the following:
yes -- Perform IP forwarding.
no -- Do not perform IP forwarding.
(The current Red Hat Linux installation sets this to "no" by default [for RFC compliance], but if FORWARD_IPV4 is not set at all, forwarding is enabled for compatibility with the configuration files used on Red Hat Linux versions 4.2 and earlier.)
GATEWAY=gw-ip, where gw-ip is the IP address of the network's gateway.
GATEWAYDEV=gw-dev, where gw-dev is the gateway device (e.g. eth0).
NISDOMAIN=dom-name, where dom-name is the NIS domain name.
The /etc/sysconfig/pcmcia file is used to specify PCMCIA configuration information. The following values may be used:
PCMCIA=answer, where answer is one of the following:
yes -- PCMCIA support should be enabled.
no -- PCMCIA support should not be enabled.
PCIC=pcic-type, where pcic-type is one of the following:
i82365 -- The computer has an i82365-style PCMCIA socket chipset.
tcic -- The computer has a tcic-style PCMCIA socket chipset.
PCIC_OPTS=option, where option is the socket driver (i82365 or tcic) timing parameters.
CORE_OPTS=option, where option is the list of pcmcia_core options.
CARDMGR_OPTS=option, where option is the list of options for the PCMCIA cardmgr (such as -q, quiet mode; -m, looks for loadable kernel modules in the specified director; and so on, read the cardmgr man page for more information).
The /etc/sysconfig/soundcard file is generated by sndconfig and should not be modified. It is used by /etc/rc.d/init.d/sound to set up your system properly. The sole use of this is to determine what card entry in the menu to pop up by default the next time sndconfig is run.
It may contain the following:
CARDTYPE=<a card>, where <a card> is seen as, for example, CARDTYPE=SB16.
The following files are normally found in /etc/sysconfig/network-scripts:
/etc/sysconfig/network-scripts/ifup
/etc/sysconfig/network-scripts/ifdown
/etc/sysconfig/network-scripts/network-functions
/etc/sysconfig/network-scripts/ifcfg-<interface-name>
/etc/sysconfig/network-scripts/ifcfg-<interface-name>-<clone-name>
/etc/sysconfig/network-scripts/chat-<interface-name>
/etc/sysconfig/network-scripts/dip-<interface-name>
/etc/sysconfig/network-scripts/ifup-post
/etc/sysconfig/network-scripts/ifdhcpc-done
Let's take a look at each one.
These are symbolic links to /sbin/ifup and /sbin/ifdown, respectively. These are the only two scripts in this directory that should be called directly; these two scripts call all the other scripts as needed. These symlinks are here for legacy purposes only -- they will probably be removed in future versions, so only /sbin/ifup and /sbin/ifdown should currently be used.
These scripts take one argument normally: the name of the device (e.g. "eth0"). They are called with a second argument of "boot" during the boot sequence so that devices that are not meant to be brought up on boot (ONBOOT=no, [see below]) can be ignored at that time.
Not really a public file. Contains functions which the scripts use for bringing interfaces up and down. In particular, it contains most of the code for handling alternative interface configurations and interface change notification through netreport.
The first file defines an interface, while the second file contains only the parts of the definition that are different in a "clone" (or alternative) interface. For example, the network numbers might be different, but everything else might be the same, so only the network numbers would be in the clone file, while all the device information would be in the base ifcfg file.
The items that can be defined in an ifcfg file depend on the interface type.
The following values are common to all base files:
DEVICE=name, where name is the name of the physical device (except dynamically-allocated PPP devices where it is the "logical name").
IPADDR=addr, where addr is the IP address.
NETMASK=mask, where mask is the netmask value.
NETWORK=addr, where addr is the network address.
BROADCAST=addr, where addr is the broadcast address.
GATEWAY=addr, where addr is the gateway address.
ONBOOT=answer, where answer is one of the following:
yes -- This device should be activated at boot-time.
no -- This device should not be activated at boot-time.
USERCTL=answer, where answer is one of the following:
yes -- Non-root users are allowed to control this device.
no -- Non-root users are not allowed to control this device.
BOOTPROTO=proto, where proto is one of the following:
none -- No boot-time protocol should be used.
bootp -- The BOOTP protocol should be used.
dhcp -- The DHCP protocol should be used.
The following values are common to all PPP and SLIP files:
PERSIST=answer, where answer is one of the following:
yes -- This device should be kept active at all times, even if deactivated after a modem hang up.
no -- This device should not be kept active at all times.
MODEMPORT=port, where port is the modem port's device name (for example, "/dev/modem").
LINESPEED=baud, where baud is the modem's linespeed (for example, "115200").
DEFABORT=answer, where answer is one of the following:
yes -- Insert default abort strings when creating/editing the script for this interface.
no -- Do not insert default abort strings when creating/editing the script for this interface.
The following values are common to all PPP files:
DEFROUTE=answer, where answer is one of the following:
yes -- Set this interface as the default route.
no -- Do not set this interface as the default route.
ESCAPECHARS=answer, where answer is one of the following:
yes -- Use the pre-defined asyncmap.
no -- Do not use the pre-defined asyncmap.
HARDFLOWCTL=answer, where answer is one of the following:
yes -- Use hardware flow control.
no -- Do not use hardware flow control.
PPPOPTIONS=options, where options is an arbitrary option string. It is placed last on the command line so it can override other options (such as asyncmap) that were specified previously.
PAPNAME=name, where name is used as part of "name $PAPNAME" on the pppd command line.
Note that the "remotename" option is always specified as the logical PPP device name, like "ppp0" (which might perhaps be the physical device ppp1 if some other PPP device was brought up earlier...), which makes it easy to manage PAP/CHAP files -- name/password pairs are associated with the logical PPP device name so that they can be managed together.
In principle, there shouldn't anything that would keep the logical PPP device names from being "worldnet" or "myISP" instead of "ppp0" -- "pppN."
REMIP=addr, where addr is the remote IP address (which is normally unspecified).
MTU=value, where value is the value to be used as MTU.
MRU=value, where value is the value to be used as MRU.
DISCONNECTTIMEOUT=value, where value represents the number of seconds to wait before re-establishing the connection after a successfully-connected session terminated.
RETRYTIMEOUT=value, where value represents the number of seconds to wait before re-attempting to establish a connection after a previous attempt has failed.
This file is a chat script for PPP or SLIP connections, and is intended to establish the connection. For SLIP devices, a DIP script is written from the chat script; for PPP devices, the chat script is used directly.
This write-only script is created from the chat script by netcfg. Do not modify this file. In the future, this file may disappear and instead will be created on-the-fly from the chat script.
This file is called when any network device (except a SLIP device) comes up. Calls /etc/sysconfig/network-scripts/ifup-routes to bring up static routes that depend on that device. Brings up aliases for that device. Sets the hostname if it is not already set and a hostname can be found for the IP for that device. Sends SIGIO to any programs that have requested notification of network events.
Could be extended to fix up name service configuration, call arbitrary scripts, and more, as needed.
This file is called by dhcpcd once DHCP configuration is complete; sets up /etc/resolv.conf from the version dhcpcd dropped in /etc/dhcpc/resolv.conf.
This section is a brief description of the internals of the boot process. It discusses how the machine boots using SysV init, as well as the differences between the init used in older Linux releases, and SysV init.
The Init program is run by the kernel at boot time. It is in charge of starting all the normal processes that need to run at boot time. These include the getty processes that allow you to log in, NFS daemons, FTP daemons, and anything else you want to run when your machine boots.
SysV init is quickly becoming the standard in the Linux world to control the startup of software at boot time, because it is easier to use and more powerful and flexible than the traditional BSD init.
SysV init also differs from BSD init in that the configuration files are in a subdirectory of /etc instead of residing directly in /etc. In /etc/rc.d, you will find rc.sysinit and the following directories:
init.d rc0.d rc1.d rc2.d rc3.d rc4.d rc5.d rc6.d |
The init.d directory contains a variety of scripts. Basically, you must have one script for each service you may need to start at boot time or when entering another runlevel. Services include things like networking, nfs, sendmail, httpd, and so on. Services do not include things like setserial that must only be run once and then exited. Things like that should go in rc.local or rc.serial.
If you want rc.local, it should be in /etc/rc.d. Most systems include one even though it doesn't do much. You can also include an rc.serial file in /etc/rc.d if you need to perform serial port specific tasks at boot time.
The chain of events is as follows:
The kernel looks in several places for init and runs the first one it finds
init runs /etc/rc.d/rc.sysinit
rc.sysinit handles most of the boot loader's processes and then runs rc.serial (if it exists)
init runs all the scripts for the default runlevel.
init runs rc.local
The default runlevel is decided in /etc/inittab. You should have a line close to the top like:
id:3:initdefault: |
From this, you'd look in the second column and see that the default runlevel is 3. If you want to change it, you can edit /etc/inittab by hand. Be very careful when you are editing the inittab file. If you do mess up, you can fix it by rebooting and typing:
LILO boot: linux single |
This should allow you to boot into single user mode so you can re-edit inittab to its previous value.
Now, how does it run all the right scripts? If you enter ls -l on rc3.d, you might see something like:
lrwxrwxrwx 1 root root 17 3:11 S10network -> ../init.d/network lrwxrwxrwx 1 root root 16 3:11 S30syslog -> ../init.d/syslog lrwxrwxrwx 1 root root 14 3:32 S40cron -> ../init.d/cron lrwxrwxrwx 1 root root 14 3:11 S50inet -> ../init.d/inet lrwxrwxrwx 1 root root 13 3:11 S60nfs -> ../init.d/nfs lrwxrwxrwx 1 root root 15 3:11 S70nfsfs -> ../init.d/nfsfs lrwxrwxrwx 1 root root 18 3:11 S90lpd -> ../init.d/lpd.init lrwxrwxrwx 1 root root 11 3:11 S99local -> ../rc.local |
What you'll notice is that there are no "real" files in the directory. Everything there is a link to one of the scripts in the init.d directory. The links also have an "S" and a number at the beginning. The "S" means to start this particular script and a "K" would mean to stop it. The number in the file name is for ordering purposes. Init will start all the services based on the order in which they appear. You can duplicate numbers, but it will only confuse you somewhat. You only need to use a two digit number, along with an upper case "S" or "K" to start or stop the services you require.
How does init start and stop services? Simple. Each of the scripts is written to accept an argument which can be "start" and "stop". You can execute those scripts by hand, in fact, with a command like:
/etc/rc.d/init.d/httpd stop |
Why all these runlevels? Some people want an easy way to set up machines to be multi-purpose. You could have a "server" runlevel that just runs httpd, sendmail, networking, etc. Then you could have a "user" runlevel that runs gdm, networking, and so on.
Generally, Red Hat Linux operates in runlevel 3 -- full multi-user mode. The following runlevels are defined in Red Hat Linux:
0 -- Halt
1 -- Single user mode
2 -- Multi-user mode, without NFS
3 -- Full multi-user mode
4 -- Not used
5 -- Full multi-user mode (with an X-based login screen)
6 -- Reboot
If your machine gets into a state where it will not boot due to a bad /etc/inittab, or will not let you log in because you have a corrupted /etc/passwd or have simply forgotten your password, boot into single user mode by typing linux single at the LILO boot prompt. A very bare system will boot and you will have a shell from which you can fix things.
The chkconfig utility provides a simple command-line tool for maintaining the /etc/rc.d directory hierarchy. It relieves system administrators from having to directly manipulate the numerous symlinks in /etc/rc.d.
In addition, there is the ntsysv utility, that provides a screen-oriented interface, versus chkconfig's command-line interface.
Please see the chkconfig and ntsysv man pages for more information.
The file /etc/rc.d/rc.local is executed at boot time, after all other initialization is complete, and whenever you change runlevels. You can add additional initialization commands here. For instance, you may want to start up additional daemons, or initialize a printer. In addition, if you require serial port setup, you can edit /etc/rc.d/rc.serial, and it will be executed automatically at boot time.
The default /etc/rc.d/rc.local simply creates a nice login banner with your kernel version and machine type.
To shut down Red Hat Linux, issue the shutdown command. You can read the shutdown man page for complete details, but the two most common usages are:
shutdown -h now shutdown -r now |
Each will cleanly shutdown the system. After shutting everything down, the -h option will halt the machine, and the -r option will reboot.
Although the reboot and halt commands are now "smart" enough to invoke shutdown if run while the system is in runlevels 1-5, it is a bad habit to get into, as not all Linux-like operating systems have this feature.