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.

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