14.5. User-Level Initialization With the start of the init process, most of the system is operating and functional. There are several additional steps taken between this point and the time a user sees a prompt to sign on to the system. All these actions are done by user-level programs that use the standard FreeBSD system-call interface that has been described in previous chapters. We shall briefly examine the steps that take place in a typical system. /sbin/init The /sbin/init program is invoked as the final step in the bootstrapping procedure. The parameters specified at the time FreeBSD was bootstrapped are passed to init in a machine-dependent fashion. Init uses the values of these flags to determine whether it should bring up the system to single-user or to multiuser operation and whether it should check the consistency of its disks with the fsck program. In single-user operation, init forks a process that invokes the standard shell, /bin/sh. The standard input, output, and error descriptors of the process are directed to the system's console terminal, /dev/console. This shell then operates normally but with superuser privileges until it terminates. In multiuser operation, init first spawns a shell to interpret the commands in the file /etc/rc, which is the root of a set of system startup scripts that do all the user-level initialization of the system. If the /etc/rc script completes successfully, init then forks a copy of itself for each terminal device that is marked for use in the file /etc/ttys. These copies of init invoke other system programs, such as /usr/libexec/getty, to manage the standard sign-on procedure. Process 1 always acts as the master coordinating process for system operation. It is responsible for spawning new processes as terminal sessions are terminated and for managing the shutdown of a running system. System Startup Scripts The /etc/rc file is mostly empty and simply serves to order and execute the various system startup scripts contained in the /etc/rc.d directory. Two files, /etc/rc.conf and /etc/defaults/rc.conf, control which user-level services are started at boot time. Each of these files is loaded by the system startup scripts when they execute. /etc/defaults/rc.conf contains the default values for various shell variables that control whether a service is to be started. Administrators override the defaults by placing different values for the same shell variables into /etc/rc.conf. For example, to enable the use of the Secure Shell (ssh) at boot time, the following line would be placed into /etc/rc.conf: sshd_enab1e ="yes"
The heart of the rc script system is a program called reorder that takes a set of shell scripts as input, works out their interdependencies, and then outputs an ordered list of names. Each startup script declares the modules that it requires as well as those it provides. The reorder programs uses these REQUIRE and PROVIDE statements to determine the proper order in which to run the startup scripts. One housekeeping task is to check the local filesystems after a system crash. If the system is not booted with the fastboot option, then the /etc/rc.d/fsck script carries out filesystem checks. In versions of BSD before FreeBSD, the filesystem checks were absolutely necessary and had to be carried out before any other work, but with the advent of soft updates (Section 8.6) and other filesystem changes, that is no longer necessary. The program /sbin/fsck checks filesystem consistency and repairs damaged filesystems. Normally, fsck is invoked from the /etc/rc.d/fsck script to examine and repair each filesystem before the latter is mounted. When the system is initially booted, the root filesystem is mounted read-only. If the root filesystem requires repairs, FreeBSD does a variant of the mount system call that requests the kernel to reload all its root-filesystem data structures. Reloading ensures consistency between the data in the kernel memory and any data in the filesystem that were modified by fsck. Having the root filesystem mounted readonly ensures that the kernel will not have any modified data in memory that cannot be reloaded. Following the filesystem checks, the filesystems are mounted, the root filesystem is updated to be writable, and any devices that are to be used for swapping and paging are enabled. Disk quotas are then checked and enabled, and the system starts the background processes that implement various system services. These processes include /usr/sbin/cron, the program that executes commands at periodic intervals; /usr/sbin/accton, the program that enables system accounting; and /usr/sbin/syslogd, the system error-logging process. Each of these processes is started from its own startup script in /etc/rc.d. /usr/libexec/getty The /usr/libexec/getty program is spawned by init for each hardware terminal line on a system. This program is responsible for opening and initializing the terminal line. As a precaution against another process opening the line and snooping on the user's input, getty uses the revoke system call to revoke access to any open descriptors on the line (see Section 6.6). It then creates a new session for the line and requests that the terminal be made the controlling terminal for the session. The getty program sets the initial parameters for a terminal line and establishes the type of terminal attached to the line. For lines attached to a modem, getty can be directed to accept connections at a variety of baud rates. Getty selects this baud rate by changing the speed of the terminal line in response to a break character or a framing error, typically generated as a result of the user hitting a break key. A user can hit successive break keys to cycle through several line speeds until the proper one is found. Getty's actions are driven by a terminal-configuration database that is located in the file /etc/gettytab. Getty finally reads a login name and invokes the /usr/bin/login program to complete a login sequence. /usr/bin/login The login program is responsible for signing a user onto the system; it is usually invoked by /usr/libexec/getty with the name of the user who wishes to log into the system. Login prompts the user for a password (after turning off terminal echoing if possible). If the password supplied by the user encrypts to the same value as that stored in the master password file /etc/master.passwd, login writes a record of the sign-on in various accounting files, initializes the user and group identifiers to those specified in the password and /etc/group files, and changes to the user's login directory. The user's login name is stored in the session structure using the setlogin system call so that it can be obtained reliably via the getlogin system call by programs that want to know the login name associated with a given process. Finally, login uses exec to overlay itself with the user's shell. The login program is also invoked when a user enters the system through a network connection. Getty and init are bypassed for such connections; their functionality is subsumed by the daemon spawned when the network connection is established. | 
