Search     or:     and:
 LINUX 
 Language 
 Kernel 
 Package 
 Book 
 Test 
 OS 
 Forum 
 iakovlev.org 
 Kernels
 Boot 
 Memory 
 File system
 0.01
 1.0 
 2.0 
 2.4 
 2.6 
 3.x 
 4.x 
 5.x 
 6.x 
 Интервью 
 Kernel
 HOW-TO 1
 Ptrace
 Kernel-Rebuild-HOWTO
 Runlevel
 Linux daemons
 FAQ
NEWS
Последние статьи :
  Тренажёр 16.01   
  Эльбрус 05.12   
  Алгоритмы 12.04   
  Rust 07.11   
  Go 25.12   
  EXT4 10.11   
  FS benchmark 15.09   
  Сетунь 23.07   
  Trees 25.06   
  Apache 03.02   
 
TOP 20
 MINIX...3057 
 Solaris...2933 
 LD...2906 
 Linux Kernel 2.6...2486 
 William Gropp...2182 
 Rodriguez 6...2016 
 C++ Templates 3...1946 
 Trees...1938 
 Kamran Husain...1866 
 Secure Programming for Li...1792 
 Максвелл 5...1711 
 DevFS...1695 
 Part 3...1684 
 Stein-MacEachern-> Час...1632 
 Go Web ...1627 
 Ethreal 4...1619 
 Стивенс 9...1607 
 Arrays...1607 
 Максвелл 1...1593 
 FAQ...1539 
 
  01.01.2024 : 3621733 посещений 

iakovlev.org

The Linux Boot Process

При включении компьютера запускается BIOS . BIOS будет пытаться прочитать первый сектор харда или флоппи . В нем по идее должна находиться программка , которую BIOS будет пытаться загрузить и выполнить . Эта программка уже в свою очередь будет пытаться прочитать операционную систему на диске и запустить уже ее .В качестве этой первичной программки может выступать LILO .
boot sector еще называется master boot record. Если пользователь с помощью LILO попытается выбрать Linux, LILO попытается загрузить линуксовое ядро, при этом произойдут следующие события :

  1. LILO will have a timeout period for the user to press the TAB key. If the user does not press the TAB key before the timeout occurs, LILO will run the default operating system selected when it was installed. If the user presses the TAB key, LILO will present the user with a choice of systems to boot from based upon the labels and images as set up in the /etc/lilo.conf file that controlled the last LILO install. This is very significant to system administrators. Let's say you have or want to install a multiple boot Linux or Linux/Windows system. Assuming you want LILO to control the boot process and you have two versions of Linux. They are Redhat, called rhl, and Slackware, called slackw. You may set each system to mount the others. Redhat will mount Slackware on a directory called /slackw and Slackware will mount Redhat on a directory called /rhl. If you want to be able to boot both systems and install LILO from Redhat, you will want your /etc/lilo.conf file to be similar to the following:
     boot=/dev/hda
     map=/boot/map
     install=/boot/boot.b
     prompt
     timeout=50
     default=rhl
     image=/boot/vmlinuz  		# Location of kernel
        label=rhl 	  			# Name of OS (for the LILO boot menu)
        root=/dev/hda1  			# Location of root partition
        read-only 	  			# Mount read only
     image=/slackw/vmlinuz 		# Location of kernel
        label=slackw 	  		# Name of OS (for the LILO boot menu)
        root=/dev/hda2  			# Location of root partition
        read-only 	  			# Mount read only
     

    Note that the Slackware kernel is located on the subdirectory /slackw which is where the Slackware operating system is installed on the Redhat system. Also be aware that the root locations may vary from system to system based upon the system configuration. The administrator will type "lilo" on the command line to install LILO after setting the configuration file up. If doing the same thing from the Slackware system, the configuration file would be as follows:

    boot=/dev/hda
     map=/boot/map
     install=/boot/boot.b
     prompt
     timeout=50
     default=rhl
     image=/rhl/boot/vmlinuz  	# Location of kernel
        label=rhl 	  			# Name of OS (for the LILO boot menu)
        root=/dev/hda1  			# Location of root partition
        read-only 	  			# Mount read only
     image=/vmlinuz	 		# Location of kernel
        label=slackw 	  		# Name of OS (for the LILO boot menu)
        root=/dev/hda2  			# Location of root partition
        read-only 	  			# Mount read only
     
  2. Since the Linux kernel is installed compressed, containing a small program to de-compress itself, it will uncompress itself.
  3. If the kernel recognizes that the system has a video card which supports some special text modes (such as 100 columns by 40 rows), Linux may ask which mode to use. The video mode and other options can be specified either during the kernel compilation or with LILO or the rdev program. Therefore the video mode can be preset, so the user is never asked.
  4. The kernel checks the hardware (hard disks, floppies, network adapters, etc), and configures some of its device drivers, while outputting messages about its findings. See an example boot output below:
    LILO boot:
     Loading linux.
     Console: colour VGA+ 80x25, 6 virtual consoles
     Calibrating delay loop... 166.71 BogoMIPS
     Memory: 
     62720k/65536k available (1008k kernel code, 412k reserved, 1052k data, 64K init)
     Checking if this processor honors the WP bit even in supervisor mode... OK.
     Buffer-cache hash table entries: 65536 (order: 9, 2097152 bytes)
     Page-cache hash table entries: 16384 (order: 4, 65536 bytes)
     VFS: Diskquotas version dquot_6.4.0 initialized
     CPU: Cyrix 6x86MX 2.5 Core/Bus Clock stepping 06
     Checking 386/387 coupling... OK, FPU using exception 16 error reporting
     Checking 'htl' instruction... OK.
     POSIX conformance testing by UNIFIX
     mtrr: v1.35a (19990819) Richard Gooch (rgooch@atmf.csiro.au)
     PCI: PCI BIOS revision 2.10 entry at 0xbf0a0
     PCI: Using configuration type 1
     PCI: Probing PCI hardware
     Linux NET4.0 for Linux 2.2
     Based upon Swansea University Computer Society NET3.039
     NET4: Unix domain sockets 1.0 for Linux NET4.0
     NET4: Linux TCP/IP 1.0 for NET4.0
     IP Protocols: ICMP, UDP, TCP, IGMP
     TCP: Hash tables configured (ehash 65536 bhash 65536)
     Initializing RT netlink socket
     Starting Kswapd v 1.5
     Detected PS/2 Mouse Port.
     Serial driver version 4.27 with MANY_PORTS MULTIPORT SHARE_IRQ enabled
     ttyS00 at 0x03f8 (irq = 4) is a 16550A
     ttyS01 at 0x02f8 (irq = 3) is a 16550A
     pty: 256 Unix98 ptys configured
     apm: BIOS version 1.2 Flags 0x07 (Driver version 1.9)
     Real Time Clock Driver v1.09
     RAM disk driver initialized: 16 RAM disks of 4096K size
     PIIX4: IDE controller on PCI bus 00 dev 39
     PIIX4: not 100%native mode: will probe irqs later
         ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio, hdb:pio
         ide1: BM-DMA at 0xf008-0xf00f, BIOS settings: hdc:pio, hdd:pio
     hda: ST36422A, ATA DISK drive
     hdb: ST36422A, ATA DISK drive
     hdd: FX240S, ATAPI CDROM drive
     ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
     ide1 at 0x170-0x177,0x376 on irq 15
     hda: ST36422A, 6103MB w/256kB Cache, CHS=778/255/63
     hdb: ST36422A, 6103MB w/256kB Cache, CHS=778/255/63
     hdd: ATAPI 24X CD-ROM drive, 256kB Cache
     Uniform CDROM driver Revision: 2.56
     Floppy drive(s): fd0 is 1.44M
     FDC 0 is a post-1991 82077
     md driver 0.90 MAX_MD_DEVS=256, MAX_REAL=12
     raid5: measuring checksumming speed
     raid5: MMX detected, trying high speed MMX checksum routines
        pII_MMX    :    252.222 MB/sec
        p5_MMX     :    291.084 MB/sec
        8regs      :    176.403 MB/sec
        32regs     :    116.967 MB/sec
     using fastest function: p5_mmx (291.084 MB/sec)
     scsi : 0 hosts.
     scsi : detected total
     md.c sizeof(mdp_super_t) = 4096
     Pattition check:
      hda: hda1 hda2 hda3 hda4
      hdb: hdb1
     RAMDISK: Compressed image found at block )
     autodetecting RAID arrays
     autorun ...
     ... autorun DONE.
     VFS: Mounted root (ext2 filesystem) readonly.
     change_root: old root has d_count=1
     Trying to unmount old root ... okay
     Freeing unused kernel memory: 64k freed
     Adding Swap: 128516k swap-space (priority -1)
     3c59x.c:
     v0.99H 11/17/98 
     Donald Becker http://cesdis.gsfc.nasa.gov/linux/drivers/vortex.html
     eth0: 3Com 3c905B Cyclone 100baseTx at 0x6800,  00:10:4b:ca:db:a1, IRQ 10
       8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Auto negotiate interface.
       MII transceiver found at address 24, status 786d.
       MII transceiver found at address 0, status 786d.
       Enabling bus-master transmits and whole-frame receives.
     eth1: 3Com 3c905B Cyclone 100baseTx at 0x6c00,  00:10:4b:ca:db:b5, IRQ 11
       8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Auto negotiate interface.
       MII transceiver found at address 24, status 7849.
       MII transceiver found at address 0, status 7849.
       Enabling bus-master transmits and whole-frame receives.
     Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
     nfsd_fh_init : initialized fhcache, entries=1024
     NET4: Linux IPX 0.38 for NET4.0
     IPX Portions Copyright (c) 1995 Caldera, Inc.
     

    The text varies on different systems, depending on the system hardware, the version of Linux being used, and the configuration.

  5. The kernel will try to mount the root filesystem. The location of the filesystem is configurable at compilation time, with the rdev program, or with LILO. The filesystem type is detected automatically. If mounting the root filesystem fails, the kernel will panic and halt the system. The root filesystem is usually mounted read-only so that the filesystem can be checked while it is mounted. This feature can also be modified using the rdev program. It is not advised to check a filesystem already mounted as read-write.
  6. The kernel starts the program "init" which becomes process number 1. Init will start the rest of the system.

    Linux Start up and Run Levels

    The Init Program

    As seen in the previous section, the kernel will start a program called init, if it finds it. The init process reads the file "/etc/inittab" and uses this file to determine how to create processes. Read the init man page for more information. Also note that init is always running and can dynamically do things and run processes based upon various signals. The administrator can also cause it to dynamically change system processes and runlevels by using the telinit program or editing the "/etc/inittab" file.

    Runlevels

    Linux utilizes what is called "runlevels". A runlevel is a software configuration of the system that allows only a selected group of processes to exist. Init can run the system in one of eight runlevels. These runlevels are 0-6 and S or s. The system runs in only one of these runlevels at a time. Typically these runlevels are used for different purposes. Runlevels 0, 1, and 6 are reserved. For Redhat Linux version 6, the runlevels are:

0-halt
1-Single user mode
2-Multiuser, without NFS (The same as 3, if you don't have networking)
3-Full multiuser mode
4-unused
5-X11
6-Reboot

The inittab file

The "/etc/inittab" file tells init which runlevel to start the system at and describes the processes to be run at each runlevel. An entry in the inittab file has the following format:

id:runlevels:action:process

  • id - A unique sequence of 1-4 characters which identifies an entry in inittab.
  • runlevels - Lists the runlevels for which the specified action should be taken. This field may contain multiple characters for different runlevels allowing a particular process to run at multiple runlevels. For example, 123 specifies that the process should be started in runlevels 1, 2, and 3.
  • action - Describes which action should be taken. Valid actions are listed below
    • respawn - The process will be restarted whenever it terminates.
    • wait - The process will be started once when the specified runlevel is entered and init will wait for its termination.
    • once - The process will be executed once when the specified runlevel is entered
    • boot - The process will be executed during system boot. The runlevels field is ignored.
    • bootwait - Same as "boot" above, but init waits for its termination.
    • off - This does nothing.
    • ondemand - This process will be executed whenever the specified ondemand runlevel is called.
    • initdefault - Specifies the runlevel which should be entered after system boot. If none exists, init will ask for a runlevel on the console. The process field is ignored.
    • sysinit - The process will be executed during system boot. It will be executed before any boot or bootwait entries. The runlevels field is ignored.
    • powerwait - The process will be executed when init receives the SIGPWR signal. Init will wait for the process to finish before continuing.
    • powerfail - Same as powerwait but init does not wait for the process to complete.
    • powerokwait - The process will be executed when init receives the SIGPWR signal provided there is a file called "/etc/powerstatus" containing the word "OK". This means that the power has come back again.
    • ctrlaltdel - This process is executed when init receives the SIGINT signal. This means someone on the system console has pressed the "CTRL-ALT-DEL" key combination.
    • kbrequest - The process will be executed when init receives a signal from the keyboard handler that a special key combination was pressed on the console keyboard.
    • process - Specifies the process to be executed. If the process starts with the '+' character, init will not do utmp and wtmp accounting for that process. This is needed for gettys that insist on doing their own utmp/wtmp housekeeping (a historic bug).
    Below is an example file:
    	# inittab       This file describes how the INIT process should set up
     	#               the system in a certain run-level.
     	#
     	# Author:       Miquel van Smoorenburg, <miquels@drinkel.nl.mugnet.org>
     	#               Modified for RHS Linux by Marc Ewing and Donnie Barnes
     	#
     
     	# Default runlevel. The runlevels used by RHS are:
     	#   0 - halt (Do NOT set initdefault to this)
     	#   1 - Single user mode
     	#   2 - Multiuser, without NFS (The same as 3, if you do not have networking)
     	#   3 - Full multiuser mode
     	#   4 - unused
     	#   5 - X11
     	#   6 - reboot (Do NOT set initdefault to this)
     	# 
     1)	id:3:initdefault:
     
     	# System initialization.
     2)	si::sysinit:/etc/rc.d/rc.sysinit
     
     3)	l0:0:wait:/etc/rc.d/rc 0
     4)	l1:1:wait:/etc/rc.d/rc 1
     5)	l2:2:wait:/etc/rc.d/rc 2
     6)	l3:3:wait:/etc/rc.d/rc 3
     7)	l4:4:wait:/etc/rc.d/rc 4
     8)	l5:5:wait:/etc/rc.d/rc 5
     9)	l6:6:wait:/etc/rc.d/rc 6
     
     	# Things to run in every runlevel.
     10)	ud::once:/sbin/update
     
     	# Trap CTRL-ALT-DELETE
     11)	ca::ctrlaltdel:/sbin/shutdown -t3 -r now
     
     	# When our UPS tells us power has failed, assume we have a few minutes
     	# of power left.  Schedule a shutdown for 2 minutes from now.
     	# This does, of course, assume you have powerd installed and your
     	# UPS connected and working correctly.  
     12)	pf::powerfail:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"
     
     	# If power was restored before the shutdown kicked in, cancel it.
     13)	pr:12345:powerokwait:/sbin/shutdown -c "Power Restored; Shutdown Cancelled"
     
     
     	# Run gettys in standard runlevels
     14)	1:2345:respawn:/sbin/mingetty tty1
     15)	2:2345:respawn:/sbin/mingetty tty2
     16)	3:2345:respawn:/sbin/mingetty tty3
     17)	4:2345:respawn:/sbin/mingetty tty4
     18)	5:2345:respawn:/sbin/mingetty tty5
     19)	6:2345:respawn:/sbin/mingetty tty6
     
     	# Run xdm in runlevel 5
     	# xdm is now a separate service
     20)	x:5:respawn:/etc/X11/prefdm -nodaemon
     
    On the left side of the file listing, above, are added numbers to help describe lines. Those lines without line numbers are either blank or begin with a "#" which means the line is a comment. Those line numbers are not part of the original file and are added here for reference purposes.
  • On line 1 above you see "id:3:initdefault:". The id is "id" which stands for initdefault. Note that it is unique on all the numbered lines. The runlevel is 3 which sets the default starting runlevel to runlevel 3. The action is initdefault which tells init to make this runlevel the default runlevel. Note that the process field is blank since it is ignored by the initdefault action.
  • Line 2 tells init to run the program "/etc/rc.d/rc.sysinit" during system boot, before any other processes.
  • Lines 3 through 9 tell init to run the program "/etc/rc.d/rc" for runlevels 0 through 6. Note that for each line the appropriate runlevel is passed to the "/etc/rc.d/rc" script program on the command line. For example note on line 5 above the second field is the runlevel specifying 2. At the end of the line there is a space and a 2 which allows the variable 2 to be passed on the command line to the program.
  • Line 10 specifies that the program "/sbin/update" will run once for every runlevel.
  • Line 11 sets up the program "/sbin/shutdown" to run when someone on the system console has pressed the "CTRL-ALT-DEL" key combination.
  • Line 12 specifies "/sbin/shutdown" to run if the power fails. Note that there are different options passed on the command line for lines 11 and 12 although they run the same program.
  • Line 13 specified "/sbin/shutdown" will run if power is restored for any of runlevels 1 through 5.
  • Lines 14 through 19 specifies the "/sbin/mingetty" program to run on 6 different terminals for runlevels 2 through 5. This means that you can run 6 virtual terminals from your keyboard simultaneously by pressing "ALT-F1" through "ALT-F6". Note pressing "ALT-F7" or above will do nothing, but the screen will not change from your current terminal.

Note the order of programs to run as specified above are:

  1. /etc/rc.d/rc.sysinit
  2. /etc/sbin/update
  3. /etc/rc.d/rc 3 - Note: we are running runlevel 3 here.

Therefore, the next thing that the system does is to run the rc.sysinit file, save buffers to the hard drive, then run system script files for the requested runlevel which will start up many system and network services as explained in the next section.

Linux Initialization Scripts

Initialization scripts run at startup include "/etc/rc.d/rc.sysinit, and /etc/rc.d/rc. The rc.sysinit script is affected by many system configuration files, some of which are listed below. The rc script file runs many other scripts that brings up many system services such as gdm and cron along with bringing up the network interfaces and other important networking functions.

rc.sysinit System Configuration Files

There are many files which affect the operation of the rc.sysinit script which are system configuration files. Some of them are listed below:

  • /etc/sysconfig/network - Controls the initial network configuration. An example file:
    NETWORKING=yes
     FORWARD_IPV4="yes"
     HOSTNAME="mdct-dev3"
     GATEWAY="10.1.0.25"
     GATEWAYDEV="eth0"
     
  • /etc/sysconfig/keyboard - The variable KEYTABLE is defined with a line like:

    KEYTABLE="us"

The name "us" may be replaced with a keymap file name such as "/etc/sysconfig/console/mykeymap".

  • /etc/sysconfig/i18n - Controls system fonts
  • /etc/sysconfig/clock - Defines if the clock is UTC or not.
  • /etc/fstab - Controls filesystems mounted at startup.
  • /etc/HOSTNAME
  • /etc/mtab - The mount command records mounted filesystems in this file.
  • /etc/conf.modules -

    The rc.sysinit Program

    This program performs many functions. Some of the most important functions are:

    1. Checking and mounting the filesystem(s).
    2. Loading the keymap.

    A summation to the majority of functions performed by this script are listed below. For more details read the "Linux Startup Reference Manual".

    1. It runs itself through the system logger "initlog" so any abnormal conditions will be reported in the log files.
    2. If the file "/etc/sysconfig/network" exists, it reads it in, but if it doesn't exist, it disables networking . The "/etc/sysconfig/network" file defines your network parameters including HOSTNAME, GATEWAY, DOMAINNAME, and GATEWAYDEV.
    3. Then a file "/etc/rc.d/init.d/functions" is loaded to provide functions to this script file for managing daemons and processes.
    4. The program "/sbin/loglevel" is used to set the initial loglevel which is initially set to 1 in "/etc/rc.d/init.d/functions". I think this has to do with how the kernel handles system logging for each terminal. For more information try typing "man syslogd" and start there.
    5. It sets and loads the keymap for the console. Line 36 gets the KEYTABLE variable value which is normally "us" in the United States. On lines 37 to 39, if the string KEYTABLE is not of length 0, and the directory /usr/lib/kbd/keymaps exists, the KEYMAP string is made equal to the string KEYTABLE which was retrieved from the file /etc/sysconfig/keyboard. The easy way to modify the key settings for the system is to modify the file /etc/sysconfig/keyboard to a new default value such as KEYTABLE="/etc/sysconfig/console/mykeymap". Type "man keymaps" or "man loadkeys" for more information.
    6. The system font is loaded by running a script program /sbin/setsysfont. This program will load/run the program "/etc/sysconfig/i18n" which can set font variables including language and possibly a screen font map and a user defined application charset map. It will first try to set these fonts using the program "consolechars" and if it can't find it, will use the program "setfont".
    7. The swap device specified in the file "/etc/fstab" is enabled for file swapping which is basically the same as the operating system using hard drive space like system memory. For more information type "man swapon" or "man swapoff".
    8. The host name and NIS domain name are then set. Type "man hostname", "man domainname", "man dnsdomainname", or "man nisdomainname" for more information. The NIS domain defines a group of computers that share configuration information. It consists of a host being the master server of the domain and all the other servers and clients rely on the master host for their configuration information. Normally most computers do not participate in an NIS domain. The program domainname can be used to set any of the domain name parameters.
    9. The options for the file system check are set up as "fsckoptions". They are set dependant upon whether the files "/fsckoptions" or "/forcefsck" exist. These options are used later in this script file.
    10. If the file "/fastboot" exists, the system filechecking is skipped. The system file checking uses the programs fsck and initlog. Type "man fsck", "man initlog" for more information. Depending on the error returned by fsck (file system check), if file system errors exist and were not corrected the system will attempt a super user login to allow the administrator to try to fix problems and then unmounts all file systems and performs a reboot. See "man sulogin", "man umount", and "man reboot".
    11. If the file "/proc/cmdline" contains the text "nopnp", then pnp ability is disabled. If PNP (plug and play) is enabled, and the file "/sbin/isapnp" is executable, and the file "/etc/isapnp.conf" exists, the executable file "/sbin/isapnp" is used with the "/etc/isapnp.conf" file to set up ISA PNP devices. For more information, type "man isapnp", "man isapnp.conf", or "man true".
    12. Then the root filesystem is remounted in read-write mode. Type "man mount" for more information. Note: remount is an option of the program mount.
    13. If an error was corrected in the filesystem above, a quota check is run. This does a filesystems scan for usage of files and directories. Type "man quotacheck", "man quotaon", or "man quotaoff" for more information.
    14. If the file "/etc/HOSTNAME" exists, the hostname from the file "/etc/sysconfig/network" is echoed to it.
    15. The file "/etc/mtab" is cleared. Then the files sytems "/ " (root) and "/proc" are mounted into mtab. Type "man mount" for more information".
    16. The ability to use modules is disabled, if the file "/proc/cmdline" contains the text "nomodules".
    17. Set up soft links for module-info and the System.map file. Uses the version of the kernel to determine required setup, then find module dependencies by running "depmod -a". Type "man depmod" for more information.
    18. The sound modules are loaded. If USEMODULES is not empty and the file "/etc/conf.modules" contains the text "alias sound" or "alias midi" then the object modules from the subdirectories "/etc/sound" or "/etc/midi" are loaded respectively. If the file "/proc/sys/kernel/modprobe" exists, and USEMODULES is enabled, the text"/sbin/modprobe" is written to the file "/proc/sys/kernel/modprobe".
    19. RAID devices are added. If the normal file "proc/mdstat" and "etc/raidtab" and the executable file "/sbin/raidadd" exist then raid devices are started using the program "/sbin/raidadd". Reading the man page for raidadd tells us that this is an obsolete RAID command. If raidadd returns 0 another obsolete RAID command "raidrun" is attempted. If this returns an error, a superuser login (sulogin) is done, filesystems are unmounted and a reboot is done.
    20. File systems are checked again with minor differences between the filesystem check above.
    21. All other filesystems except for NFS and /proc are mounted (they are already mounted). nonfs, smbfs, ncpfs, and proc are mounted.
    22. If the executable file "/sbin/quotaon" exists it is run.
    23. Various files are deleted.
    24. The time of file /var/run/wtmp is updated (See "man touch").
    25. File permissions and groups are changed for "/var/run/utmp" and /var/run/wtmp".
    26. The system clock is set. The file "/etc/sysconfig/clock" is loaded. The values ARC and UTC are set dependent on the values in "/etc/sysconfig/clock" and CLOCKMODE. In my systems case, these are both false. The string values "$CLOCK" and "$CLOCKFLAGS" are set up dependent on files and options as shown below. If the file "/sbin/hwclock" exists, it will be run with the option "hctos" to set the system time from the hardware clock. Also the option "—adjust" is added to adjust for clock drift. If the above file "/sbin/hwclock" doesn't exist the "/sbin/clock" program will be run. If the "UTC" option is enabled then the "-u" option is added to CLOCKFLAGS. This allows for the hardware clock to be set in Coordinated Universal Time rather than local time.
    27. Swap space is turned on. Type "man swapon" for more information.
    28. The serial ports are initialized. If the file "/etc/rc.d/rc.serial" it is loaded resident. It doesn't exist on my system.
    29. Load modules (for backward compatibility with VARs). If the file "/etc/rc.d/rc.modules" exists, it is loaded. The script does not indicate it is loaded resident, but I wonder if this is a typo???
    30. If a SCSI tape is detected, load the st module unconditionally.
    31. Set the preferred X display manager link. If the file "/etc/sysconfig/desktop" contains the text "GNOME" preferred is set to "gdm". If "KDE" it is set to kde. If "AnotherLevel" it is set to xdm. In the statement "if [-n "$preferred" ] && which $preferred >/dev/null 2>&1;" the condition is met if the string "$preferred" has length, and the program "which" has any error or standard output greater than null.
    32. Dump the syslog ring so we can find it later. The program dmesg is used to output the kernel logging to the file "/var/log/dmesg". Type "man dmesg" for more information.

    The update Daemon

    The program "init" invokes the command "/sbin/update" which causes a daemon called bdflush to run. In fact if you type "man update" you will most likely get a man page about the daemon bdflush. This deamon causes the kernel to flush dirty buffers back to disk. There is a kernel function that does most of the work and bdflush forks a new process which calls the kernel function that will never return. What is meant by dirty buffers, is memory pages, or virtual memory pages that have been changed, but not saved to the swap disk. I'm glad that's cleaned up!

    The rc script Program

    The script file /etc/rc.d/rc is run for the appropriate runlevel (typically 3 or 5) This file does the following:

    1. It gets the previous and current system runlevels.
    2. If the word confirm is in the file "/proc/cmdline" if sets up to run the scripts below in user confirmation mode.
    3. All kill files (files whose first letter is 'K') in the subdirectory "/etc/rc.d/rc3.d" (assuming the previous runlevel was 3) are run. The parameter stop is usually passed on the command line to the kill script.
    4. All startup files (files whose first letter is 'S") in the subdirectory "/etc/rc.d/rc5.d" (assuming the current runlevel is 5) are run. The parameter start is usually passed on the command line to the kill script.

    Subsystem Script Programs

    The subsystem script program is usually a softlink to a corresponding program in the "/etc/rc.d/init.d" directory. At the start of a typical subsystem script, checks are done to be sure the service can be run, then depending on whether start, stop, restart, or status was passed on the command line a case statement will take the appropriate action. More is said about these scripts in a later section.

    The rc.local Script Program

    The file "/etc/rc.d/rc3.d/S99.local" is a link file to the file "/etc/rc.d/rc.local". This file doesn't do much except for setting up the "/etc/issue" and "/etc/issue.net" files to reflect the system version when a user begins a terminal or telnet session. This is where most administrators will put any system customizations they want to make.

    Linux Run level scripts

    The runlevel scripts are used to bring up many system and networking functions. Since some functions are interdependent on other functions there is some required order in which these scripts must be run in order to bring the system up and to bring it gracefully down. Each runlevel has its own set of start(S) and kill(K) scripts but all these scripts are supported in the directory /etc/rc.d/init.d. This is because the start and kill scripts are soft links to the files in the /etc/rc.d/init.d directory.

    The rc script Program

    The script file /etc/rc.d/rc is run for the appropriate runlevel (typically 3 or 5) This file does the following:

    1. It gets the previous and current system runlevels.
    2. If the word confirm is in the file "/proc/cmdline" if sets up to run the scripts below in user confirmation mode.
    3. All kill files (files whose first letter is 'K') in the subdirectory "/etc/rc.d/rc3.d" (assuming the previous runlevel was 3) are run. The parameter stop is usually passed on the command line to the kill script.
    4. All startup files (files whose first letter is 'S") in the subdirectory "/etc/rc.d/rc5.d" (assuming the current runlevel is 5) are run. The parameter start is usually passed on the command line to the kill script.

    These runlevel scripts are used to bring up (or down) various system services such as cron and gpm along with networking services from the network cards through Samba, and servers like DNS, DHCP, and NFS. A directory listing of the files in the /etc/rc.d/init.d will reveal the many possible services that the system can support.

    drwxr-xr-x   2 root     root         4096 May  5 10:00 .
     drwxr-xr-x  10 root     root         4096 Apr 28 04:08 ..
     -rwxr-xr-x   1 root     root          766 Sep 13  1999 amd
     -rwxr-xr-x   1 root     root         1231 Sep 20  1999 apmd
     -rwxr-xr-x   1 root     root          827 Sep  9  1999 arpwatch
     -rwxr-xr-x   1 root     root          989 Aug 16  1999 atd
     -rwxr-xr-x   1 root     root         4816 Sep 20  1999 autofs
     -rwxr-xr-x   1 root     root         1011 Dec 20 08:21 bootparamd
     -rw-------   1 root     root      1101824 Mar  2 11:25 core
     -rwxr-xr-x   1 root     root         1031 Sep 10  1999 crond
     -rwxr-xr-x   1 root     root          975 Apr 28 04:19 dhcpd
     -rwxr-xr-x   1 root     root         7386 Sep 20  1999 functions
     -rwxr-xr-x   1 root     root         1417 Aug 16  1999 gated
     -rwxr-xr-x   1 root     root         1261 Sep 24  1999 gpm
     -rwxr-xr-x   1 root     root         3129 Sep 20  1999 halt
     -rwxr-xr-x   1 root     root          865 Sep 21  1999 httpd
     -rwxr-xr-x   1 root     root         1151 Sep 13  1999 identd
     -rwxr-xr-x   1 root     root         1463 Sep 10  1999 inet
     -rwxr-xr-x   1 root     root         1924 Aug 30  1999 innd
     -rwxr-xr-x   1 root     root         6029 Sep 24  1999 isdn
     -rwxr-xr-x   1 root     root         1203 Sep  5  1999 keytable
     -rwxr-xr-x   1 root     root          449 Sep 11  1999 killall
     -rwxr-xr-x   1 root     root         1172 Sep 24  1999 kudzu
     -rwxr-xr-x   1 root     root         1890 Sep 13  1999 ldap
     lrwxrwxrwx   1 root     root         43 Dec 17 05:25 
     -rwxr-xr-x   1 root     root         1176 Sep 10  1999 lpd
     -rwxr-xr-x   1 root     root         1104 Sep 10  1999 mars-nwe
     -rwxr-xr-x   1 root     root         1171 Sep 24  1999 mcserv
     -rwxr-xr-x   1 root     root         1331 Sep 24  1999 named
     -rwxr-xr-x   1 root     root         3217 Sep 20  1999 netfs
     -rwxr-xr-x   1 root     root         6573 Sep 21  1999 network
     -rwxr-xr-x   1 root     root         2257 Sep 24  1999 nfs
     -rwxr-xr-x   1 root     root         1722 Sep 24  1999 nfslock
     -rwxr-xr-x   1 root     root         1603 Sep 20  1999 nscd
     -r-xr-xr-x   1 root     root         3439 Sep 27  1999 pcmcia
     -rwxr-xr-x   1 root     root         1086 Sep 10  1999 portmap
     -rwxr-xr-x   1 root     root         2435 Sep 26  1999 postgresql
     -rwxr-xr-x   1 root     root         1260 Sep 25  1999 pulse
     -rwxr-xr-x   1 root     root          955 Sep 26  1999 pxe
     -rwxr-xr-x   1 root     root         1532 Feb  4  1999 random
     -rwxr-xr-x   1 root     root         1270 Sep 10  1999 routed
     -rwxr-xr-x   1 root     root          780 Sep 22  1999 rstatd
     -rwxr-xr-x   1 root     root          974 Sep 22  1999 rusersd
     -rwxr-xr-x   1 root     root          941 Aug 16  1999 rwalld
     -rwxr-xr-x   1 root     root          882 Sep  9  1999 rwhod
     -rwxr-xr-x   1 root     root         1549 Sep  1  1999 sendmail
     -rwxr-xr-x   1 root     root         1451 Apr 15  1999 single
     -rwxr-xr-x   1 root     root         1177 Sep 25  1999 smb
     -rwxr-xr-x   1 root     root          851 Aug 31  1999 snmpd
     -rwxr-xr-x   1 root     root         2306 Sep 11  1999 squid
     -rwxr-xr-x   1 root     root         1027 Dec 21 14:04 syslog
     -rwxr-xr-x   1 root     root         1033 Jan 10 06:40 xfs
     -rwxr-xr-x   1 root     root         1212 Aug 16  1999 xntpd
     -rwxr-xr-x   1 root     root         1575 Sep 22  1999 ypbind
     -rwxr-xr-x   1 root     root         1084 Aug 17  1999 yppasswdd
     -rwxr-xr-x   1 root     root         1137 Aug 17  1999 ypserv
     

    These services are can be functionally categorized as a system service or a network service. They are described in more detail in the section on Daemons and Services. For more information on how some of the script files for these services run, read the Linux startup Manual. Normally any of these services may be stopped, started, restarted, or status be checked by typing the name of one of these services (with the correct path) followed by the word stop, start, restart, or status respectively. For example the line:

    /etc/rc.d/init.d/nfs restart

    will restart network file sharing assuming it was running. To see the status type:

    /etc/rc.d/init.d/nfs status

    The rc.local Script Program

    The file "/etc/rc.d/rc3.d/S99.local" is a link file to the file "/etc/rc.d/rc.local". This file doesn't do much except for setting up the "/etc/issue" and "/etc/issue.net" files to reflect the system version when a user begins a terminal or telnet session. This is where most administrators will put any system customizations they want to make.

    The Linux Login Process

    After the system boots, at serial terminals or virtual terminals, the user will see a login prompt similar to:

    machinename login:

    This prompt is being generated by a program, usually getty or mingetty, which is regenerated by the init process every time a user ends a session on the console. The getty program will call login, and login, if successful will call the users shell. The steps of the process are:

    1. The init process spawns the getty process.
    2. The getty process invokes the login process when the user enters their name and passes the user name to login.
    3. The login process prompts the user for a password, checks it, then if there is success, the user's shell is started. On failure the program displays an error message, ends and then init will respawn getty.
    4. The user will run their session and eventually logout. On logout, the shell program exits and we return to step 1.

    Note: This process is what happens for runlevel 3, but runlevel 5 uses some different programs to perform similar functions. These X programs are called X clients.

    The init process revisited

    Recall that in /etc/inittab file there were lines like this:

    1:2345:respawn:/sbin/mingetty tty1

    These lines cause init to spawn the mingetty process on runlevels 2 through 5 for tty1 and other terminals. To do this init will use the "fork" function to make a new copy of itself and use an "exec" function to run the mingetty program. Getty will wait for the user, then read the username. Then mingetty will invoke login with the user's name as an argument. If the password entered does not match for the user, init will load and run mingetty again. If the login is successful, init will use the "exec" function to run the user's shell program. When the shell exits through the "logout" command, init will load and run the mingetty program again (the reason for the "respawn" command in the /etc/inittab file). The file "/etc/passwd" determines the shell to be used for the user who is logging in. This version of Linux uses the mingetty program which is a minimum getty program used for virtual terminals. On some systems and normally Unix systems traditionally the getty program is used which has more capabilities. In this section, the getty program is described, but you should be aware that many of the special features of getty will not apply to mingetty.

    Note that network logins are handled differently than console logins since it is impractical to have a getty provided for each potential network login. Network logins are normally handled through the internet super daemon, inetd using either the telnet or rlogin communication protocol. The telnet daemon will invoke the login program when a session starts, then if successful, the login program will invoke the user's shell.

    Getty

    Getty performs the following functions:

    1. Open tty lines and set their modes
    2. Print the login prompt and get the user's name
    3. Begin a login process for the user

    A detailed analysis:

    1. At startup, it parses its command line, then reads it's default file, usually "/etc/conf.getty" to determine runtime values. After setting up the "line" or virtual line, getty outputs the contents of the "/etc/issue" file. Then getty reads the user's name and invokes login with the user's name as an argument. While reading the user's name, getty attempts to adapt the system to the speed of the terminal being used, and also sets certain terminal parameters to conform with the user's login procedure. See the termio man page.
    2. The tty device used by getty is determined by the argument on the command line. This argument is normally determined by the entry in /etc/inittab. The speed argument is a label to an entry in the "/etc/gettydefs" file. this entry defines the initial speed and tty settings, the login prompt to be used, the final speed and tty settings and a pointer to another entry to try if the user indicates that the speed is not correct. This is done by sending a break character.
    3. Getty scans the gettydefs file looking for a matching entry to the speed. The first entry is used if no speed was given or no match was found.
    4. The type argument names the type of terminal attached to the line such as 3101. The type should be a valid name listed in the termcap database. Getty uses this value to determine how to clear the video display and sets the environment variable "TERM" to the contents of this value. On most Linux systems, this value will be "linux".
    5. The lined argument describes the line discipline to use on the line. The default is "LDISC0".

    During its startup, getty looks for the file "/etc/conf.getty.line" or "/etc/conf.getty". It reads the contents for lines with the form "NAME=value". The name strings are listed below:

    • SYSTEM=name - Sets the nodename value. The default is the value returned by uname(3) which returns your system information, usually "Linux".
    • VERSION=string - Sets the @V parameter to the value of the string or the contents of the file (if the string begins with "/") pointed to by the string.
    • LOGIN=name - The name of the login program to be run when the user enters their name. The default is /bin/login.
    • INIT=string - A string used to initialize the line before being used by getty
    • ISSUE=string - This string is typed rather than the contents of the /etc/issue file.
    • CLEAR=value
    • HANGUP=value
    • WAITCHAR=value
    • DELAY=seconds
    • TIMEOUT=number
    • CONNECT=string
    • WAITFOR=string
    • ALTLOCK=line
    • ALTLINE=line
    • RINGBACK=value
    • SCHED=range1 range2 range3
    • OFF=string
    • FIDO=string
    • EMSI=value

    These commands are explained better in the getty(1m) man page.

    Login

    The login program will prompt for the user name if no argument is given on the command line.

    If the file "/etc/nologin" exists and the user is not root, the contents of the "/etc/nologin" file are printed to the screen and the login is terminated. If special access restrictions are specified for the user logging in in the file "etc/usertty", the restrictions must be met or the log in will be denied and the program syslog will log the attempt. If the user is root the login must be on a terminal listed in the file "etc/securetty".

    If the above conditions are met, the user password will be requested and then it will be checked (If a password is required for this username). After three unsuccessful attempts to login the response gets very slow, and after 10 attempts, login dies. As usual all login failures will be reported by the syslog facility. If the file ".hushlogin" exists in the user's home directory then a "quiet" login is performed which disables checking of mail and the printing of the last login time and the message of the day. Otherwise if the file "var/log/lastlog" exists the last login time is printed and then the current login is recorded in this file. Is the current login recorded in this file if it does not already exist or if the file ".hushlogin" exists? I think it does but have found no documentation that says.

    At this point the login program will perform standard administrative tasks. These include:

    1. Setting the UID and GID of the tty
    2. Preserving the TERM environment variable if it exists.
    3. Preserving other environment variables if the –p option is used
    4. The HOME, PATH, SHELL, TERM, MAIL, and LOGNAME environment variables are set.
    5. The default path is set to "/usr/local/bin:/bin:/usr/bin:." for normal users and "/sbin:/bin:/usr/sbin" for root.
    6. If this is not a "quiet" login, the message of the day is printed and the file with the user's name in "/usr/spool/mail" will be checked and a message will be printed if it has non-zero length.
    7. The users shell is started. The shell is specified in the file "/etc/passwd". If it is not specified, login will use "/bin/sh" as a default shell. This shell will be run with the user's privileges rather than root privileges as login was run.
    8. If there is no directory specified for the user in "/etc/passwd", login will use "/" by default for the user's home directory.

    Another function that login will perform is to update the user accounting login files which are "/var/run/utmp" and "var/log/wtmp" which hold information about the amount of time users have been on the system along with when they logged on and off. Also the init program and getty may write to these files.

    How login uses the /etc/passwd file:

    Once the user has successfully logged in, the login program will invoke the user's shell. The login program will look in the /etc/passwd file to determine which shell program to run. The /etc/passwd file contains entries containing the complete path of the shell. A sample /etc/passwd file is listed below:

    root:x:0:0:root:/root:/bin/bash
     bin:x:1:1:bin:/bin:
     daemon:x:2:2:daemon:/sbin:
     adm:x:3:4:adm:/var/adm:
     lp:x:4:7:lp:/var/spool/lpd:
     sync:x:5:0:sync:/sbin:/bin/sync
     shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
     halt:x:7:0:halt:/sbin:/sbin/halt
     mail:x:8:12:mail:/var/spool/mail:
     news:x:9:13:news:/var/spool/news:
     uucp:x:10:14:uucp:/var/spool/uucp:
     operator:x:11:0:operator:/root:
     games:x:12:100:games:/usr/games:
     gopher:x:13:30:gopher:/usr/lib/gopher-data:
     ftp:x:14:50:FTP User:/home/ftp:
     nobody:x:99:99:Nobody:/:
     xfs:x:100:101:X Font Server:/etc/X11/fs:/bin/false
     gdm:x:42:42::/home/gdm:/bin/bash
     postgres:x:40:233:PostgreSQL Server:/var/lib/pgsql:/bin/bash
     squid:x:23:23::/var/spool/squid:/dev/null
     mark:x:500:500::/home/mark:/bin/bash
     george:x:501:501::/home/george:/bin/bash
     

    the syntax is:

    account:password:UID,GID,GECOS:directory:shell

    where the fields are defined as:

    • account - The user's name.
    • password - The users encrypted passwrod or a place holding character if the system is using shadow passwords and storing the password in the /etc/shadow file which is readable only by root.
    • UID - The users numerical identification.
    • GID - The number of the primary group for the user.
    • GECOS - Usually has the full user name. This field is only for information purposes and is optional. This information is sometimes called the user's finger information.
    • directory - The full path of the user's home directory.
    • shell - The full path and filename of the user's shell. If no value is here /bin/sh is assumed. This value can be changed with the chsh command.

    The login program will use the account field to find the username and therefore get the UID of the user. Login will also use the password (or the /etc/shadow file) to be sure the entered password is a match. Login will look up the user's home directory and use that to set the $HOME environment variable. Login will use the shell field to determine what shell program (such as bash, sh, tsh, etc) to run for that user. then login will pass program control to the shell program. There is an important difference in the control passed at this point, however! The shell program will run with the user's privileges and not with root privileges. The programs to this point (init, getty, login) have all run with root privileges.

    Files used by the login program:

    • /etc/nologin - This file is used to prevent users who are not root from logging into the system.
    • /etc/usertty - This file is used to impose special access restrictions on users.
    • /etc/securetty - Controls the terminals that the root user can login on.
    • .hushlogin - When this file exists in the user's home directory, it will prevent check for mail, printing of the last login time, and the message of the day when the user logs in.
    • /var/log/lastlog - Contains information about the last time a login was done on the system.
    • /etc/passwd - Contains information about the user including the ID, name, home directory, and the path to the preferred shell program. If not using shadow passwords, this file may also contain user passwords.
    Оставьте свой комментарий !

    Ваше имя:
    Комментарий:
    Оба поля являются обязательными

     Автор  Комментарий к данной статье