When you hit the power button on your computer a whole lot of stuff happens. We call this the boot process. In the days when I first started using computers there was literally a "boot disk", a floppy (5.25" not a 3.5") disk that told the system where to go and what to do so that the operating system would start up. Since then the boot sequence has become somewhat more complicated. So let me take you thru the steps the computer takes to get started. For my example I'm going to use a Windows XP system.
1. First is the POST, this stands for Power On Self Test, for the computer. This process tests memory as well as a number of other subsystems. You can usually monitor this as it runs each test. After that is complete the system will run POST for any device that has a BIOS (Basic Input-Output System). An AGP has its own BIOS, as do some network cards and various other devices.
2. Once the POST is complete and the BIOS is sure that everything is working properly, the BIOS will then attempt to read the MBR (Master Boot Record). This is the first sector of the first hard drive (called the Master or HD0). When the MBR takes over it means that Windows is now in control.
3. The MBR looks at the BOOT SECTOR (the first sector of the active partition). That is where NTLDR is located, NTLDR is the BOOT LOADER for Windows XP. NTLDR will allow memory addressing, initiate the file system, read the boot.ini and load the boot menu. NTLDR has to be in the root of the active partition as do NTDETECT.COM, BOOT.INI, BOOTSECT.DOS (for multi-OS booting) and NTBOOTDD.SYS (if you have SCSI adapters)
4. Once XP is selected from the Boot Menu, NTLDR will run NTDETECT.COM, BOOT.INI and BOOTSECT.DOS to get the proper OS selected and loaded. The system starts in 16-bit real mode and then moves into 32-bit protected mode.
5. NTLDR will then load NTOSKRNL.EXE and HAL.DLL Effectively, these two files are windows XP. They must be located in %SystemRoot%System32.
6. NTLDR reads the registry, chooses a hardware profile and authorizes device drivers, in that exact order.
7. At this point NTOSKRNL.EXE takes over. It starts WINLOGON.EXE that in turn starts LSASS.EXE, this is the program that display the Logon screen so that you can logon.
After POST, the firmware (System Read Only Storage) detects the 1stbootable device stored in the bootlist. (here it is hdisk0)
then the bootstrap code (software ROS) i.e. 1st 512 bytes of the hard disk loads to RAM.
Bootstrap code locates the Boot Logical Volume (BLV = hd5) from the harddisk
BLV contains AIX kernel, rc.boot Script, Reduced ODM and Bootcommands.
Then BLV in the RAM uncompresses and Kernel releases from it.
Then AIX Kernel gets control.
AIX Kernel creates a RAM File System (Rootvg not activated now).
kernel starts init process from the BLV.
init executes rc.boot script from the BLV in the RAM.
Init with rc.boot 1 configures base devices.
rc.boot 1 in detail
init process from RAMFS executes rc.boot 1 (if any error LED=c06)
restbase command copies ODM from BLV to RAMFS.(success LED=510, error LED=548)
cfgmgr -f calls Config_rules ( which are phase=1) and activates all base devices.
run command bootinfo -b to check last boot device ( success LED=511).
Then
rc.boot 2 activates rootvg from hard disk.
rc.boot 2 in detail
rc.boot 2 (LED 551)
ipl_varyon to activate rootvg ( success LED= 517, error LED=552,554,556).
run command fsck -f /dev/hd4 to check whether "/" unmounted uncleanely in the last shutdown ( error LED=555).
mount /dev/hd4 (/) to RAMFS (error LED=557 due to corrupted jfslog..)
fsck -f /dev/hd2 i.e. "/usr" ( error LED=518).
mount /dev/hd2 in RAMFS.
fsck -f /dev/hd9var i.e. check "/var"
mount /var
copycore command checks whether dump occured. then copy dump from primary dump device paging space (/dev/hd6) to /var/adm/ras/.
unmount /var
swapon /dev/hd6 i.e. activate primary paging space.
Now the condition is /dev/hd4 is mounted on / in the RAMFS; cfgmgr -f configured all base devices . so configuration data has been written to ODM of RAMFS.
mergedev is called and copy /dev from RAMFS to disk.
copy customized ODM from RAMFS to hard disk(at this stage both ODM from hd5 and hd4 are sync now)
mount /var.
Boot messages copy to file on the hard disk ( /var/adm/ras/bootlog) alog -t boot -o to view bootlog
Now / , /usr and /var are mounted in rootvg on the hard disk. Then
Kernel removes RAMFS
init process start from / in the rootvg
Here completes rc.boot 2, Now the condition is kernel removed RAMFS and accessing rootvgfilesystems from hard disk. init from BLVreplaced by initfrom hard disk
in rc.boot 3, init process /etc/inittab file and remainingdevices are configured.
rc.boot 3 in detail
/etc/init starts and reads /etc/inittab ( LED=553)
runs /sbin/rc.boot 3
fsck -f /dev/hd3 i.e. check /tmp.
mount /tmp
sysncvg rootvg &; i.e. run syncvg in background and report stale PPs.
cfgmgr -P2 i.e. run cfgmgr in phase 2 in normal startup. (cfgmgr -P3 in service mode)
All remaining devices are configured now.
cfgcon configures console ( LED= c31 select console, c32 lft, c33 tty, c34 file on disk). If CDE mentioned in /etc/inittab we will get graphical console.
savebase calls to sync ODM from BLV with / FS (i.e. /etc/objrepos).
syncd daemon started. All data from cache memory to disk saves in every 60 seconds.
starts errdaemon for error logging.
LED display turned OFF.
rm /etc/nologin i.e. if the file is not removed, then login is not possible.
If any device are in missed state, (in Cudv chgstatus=3) display it.
Display "system initialization completed"
Then execute next line from /etc/inittab
DETAILED
=======
I. The boot process in AIX
As a system administrator you should have a general understanding of theboot process. This knowledge is useful to solve problems that can prevent asystem from booting properly. These problems can be both software or hardware.We also recommend that you be familiar with the hardware configuration ofyour system.
Booting involves the following steps:
The initial step in booting a system is named Power On Self Test (POST). Itspurpose is to verify that basic hardware is in functional state.Thememory, keyboard, communication and audio devices are also initialized. You cansee an image for each of these devices displayed on the screen. It is duringthis step that you can press a function key to choose a different boot list.The LED values displayed during this phase are model specific. Both hardware and software problems can prevent the system from booting.
System Read Only Storage (ROS) is specific to each system type. It is necessary for AIX 5L Version 5.3 to boot, but it does not build the datastructures required for booting. It will locate and load bootstrap code.System ROS contains generic boot information and is operating systemindependent. Software ROS (also named bootstrap) forms an IPL control block whichis compatible with AIX 5L Version 5.3, takes control and builds AIX 5L specific boot information. A special file system located in memory and namedRAMFS file system is created. Software ROS then locates, loads, and turnscontrol over to AIX 5L Boot Logical Volume (BLV). Software ROS is AIX 5Linformation created based on machine type and is responsible for completing machinepreparation to enable it to start AIX 5L kernel. A complete list of files that are part of the BLV can be obtained from directory /usr/lib/boot.
The most important components are the following:
- The AIX 5L kernel - Boot commands called during the boot process such as bootinfo, cfgmgr - A reduced version of the ODM. Many devices need to be configuredhd4 (/) made available, so their corresponding methods have to bestored in the BLV. These devices are marked as base in PdDv. - The rc.boot script
Note: Old systems based on MCI architecture execute an additional stepbefore this, the so called Built In Self Test (BIST). This step is nolonger required for systems based on PCI architecture.
The AIX 5L kernel is loaded and takes control. The system will display 0299 on the LED panel. All previous codes are hardware-related. The kernelwill complete the boot process by configuring devices and starting the initprocess. LED codes displayed during this stage will be generic AIX 5Lcodes. So far, the system has tested the hardware, found a BLV, created theRAMFS, and started the init process from the BLV. The rootvg has not yet beenactivated. From now on the rc.boot script will be called three times,each timebeing passed a different parameter.
1.Boot phase 1
During this phase, the following steps are taken:
The init process started from RAMFS executes the boot script rc.boot
If init process fails for some reason, code c06 is shown on LED display. At this stage, the restbase command is called to copy a partial image of ODM from the BLV into the RAMFS. If this operation is successful LED display shows 510, otherwise LED code 548 is shown.
After this, the cfgmgr -f command reads the Config_Rules class from the reduced ODM. In this class, devices with the attribute phase=1 are considered base devices. Base devices are all devices that are necessary to access rootvg. For example, if the rootvg is located on a hard disk all devices starting from motherboard up to the disk will have to be initialized.The corresponding methods are called so that rootvg can be activated in the nextboot phase 2. At the end of boot phase 1, the bootinfo -b command is called to determine the last boot device. At this stage, the LED shows 511.
2.Boot phase 2
In this phase , the rc.boot script is passed to the parameter 2. During this phase the following steps are taken.
a) The rootvg volume group is varied on with the special version of the varyonvg command ipl_varyon. If this command is successful the system displays 517. otherwise one of the following LED will appear 552,554,556 and the boot process is halted.
b) Root file system hd4 is checked using the fsck -f command. This will verify only whether the filesystem was unmounted cleanly before the last shutdown. If this command fails, the system will display code 555.
c) The root file system ( /dev/hd4 ) is mounted on a temporary mount point /mnt in RAMFS. If this fails 557 will appear in LED. d) The /usr file system is verified using fsck -f command and then mounted. the copycore command checks if a dump occured. if it did, it is copied from default dump devices, /dev/hd6 to the default copy directory /var/adm/ras. After this /var is unmounted.
e) The primary pagingspace from rootvg, /dev/hd6 will be activated.
f) The mergedev process is called and /dev files from RAMFS are copied to disk.
g) All customized ODM files from the RAMFS are copied to disk.Both ODM versions from hd4 and hd5 are synchronized.
h) Finaly, the root file system from rootvg (disk) is mounted over the root file system from the RAMFS. The mount points for the root filesystems become available. now the /var and /usr file systems from the rootvg are mounted again on their ordinary mount points. There is no console available at this stage; so all boot messages will be copied to alog. The alog command maintains and manages logs.
3.Boot Phase 3 After phase 2 is completed rootvg is activated and the following steps are taken,
a. /etc/init process is started. It reads /etc/inittab file and calls rc.boot with argument 3
b. The /tmp filesystem is mounted.
c. The rootvg is synchronized by calling the synchvg command and launching it as background process. As a result all stale partitions from rootvg are updated.At this stage LED code 553 is shown. d. At this stage the cfgmgr command is called.if the system is booted in normal mode the cfgmgr command is called with option -p2; in service mode, option -p3. The cfgmgr command reads the Config_rules files from ODM and calls all methods corresponding to either phase 2 or 3. All other devices that are not base devices are configured at this time.
e. Next the console is configured by calling the cfgcon command. After the configuration of the console , boot messages are send to the console if no STDOUT redirection is made. However all missed messages can be found in /var/adm/ras/conslog. LED codes that can be displayed at this time are :
c31 = console not yet configured. c32 = console is an LFT terminal. c33 = console is a TTY. c34 = console is a file on the disk.
f. finally the synchronization of the ODM in the BLV with the ODM from the / (root) filesyatem is done by the savebase command.
g. The syncd daemon and errdaemon are started.
h. LED display is turned off.
i. if the /etc/nologin exists, it will be removed.
j. If there are devices marked as missing in CuDv a message is displayed on the console.
i. the message system initialization completed is send to the console. the execution of the rc.boot has completed. init process will continue processing the next command from /etc/inittab. II. system initialization
During system startup, after the root file system has been mounted in the pre-initialization process, the following sequence of events occurs:
1. The init command is run as the last step of the startup process. 2. The init command attempts to readthe /etc/inittab file. 3. If the /etc/inittab file exists, the init command attempts to locate an initdefauult entry in the /etc/inittab file.
a. If the initdefault entry exists, the init command uses the specified runlevel as the initial system run level. b. If the initdefault entry does not exist, the init command requests that the user enter a run level from the system console (/dev/console). c. If the user enters an S, s, M, or m run level, the init command enters the maintenance run level. These are the only runlevels that do not require a properly formatted /etc/inittab file.
4. If the /etc/inittab file does not exist, the init command places the system in the maintenance run level by default. 5. The init command rereads the /etc/inittab file every 60 seconds. If the /etc/inittab file has changed since the last time the init command read it, the new commands in the /etc/inittab file are executed.
III. The /etc/inittab file
The /etc/inittab file controls the initialization process.
The /etc/inittab file supplies the script to the init command's role as a general process dispatcher. The process that constitutes the majority of the init command's process dispatching activities is the /etc/getty line process, which initiates individual terminal lines. Other processes typically dispatched by the init command are daemons and the shell.
The /etc/inittab file is composed of entries that are position-dependent and have the following format,
/etc/inittab format = Identifier:RunLevel:Action:Command
Each entry is delimited by a newline character. A backslash (\) preceding a new line character indicated the continuation of an entry. There are no limits (other than maximum entry size) on the number of entries in the /etc/inittab file.
The maximum entry size is 1024 characters.
The entry fields are :
Identifier A one to fourteen character field that uniquely identifies an object.
RunLevel The run level at which this entry can be processed. The run level has the following attributes:
-Run levels effectively correspond to a configuration of processes in the system.
-Each process started by the init command is assigned one or more run levels in which it can exist.
-Run levels are represented by the numbers 0 through 9.
Eg: if the system is in run level 1, only those entries with a 1 in the run-level field are started.
-When you request the init command to change run levels, all processes without a matching entry in the run-level field for the target run level receive a warning signal (SIGTERM). There is a 20-second grace period before processes are forcibly terminated by the kill signal (SIGKILL).
-The run-level field can define multiple run levels for a process by selecting more than one run level in any combination from 0 through 9. If no run level is specified, the process is assumed to be valid at all run levels.
-There are four other values that appear in the run-level field, even though they are not true run levels: a, b, c and h. Entries that have these characters in the run level field are processed only when the telinit command requests them to be run (regardless of the current run level of the system). They differ from run levels in that the init command can never enter run level a, b, c or h. Also, a request for the execution of any of these processes does not change the current run level. Furthermore, a process started by an a, b, or c command is not killed when the init command changes levels. They are only killed if their line in the /etc/inittab file is marked off in the action field, their line is deleted entirely from /etc/inittab, or the init command goes into single-user mode.
Action It tells the init command how to treat the process specified in the process field. The following actions are recognized by the init command:
respawn If the process does not exist, start the process. Do not waitfor its termination (continue scanning the /etc/inittab file). Restart the process when it dies. If the process exists, do nothing and continue scanning the /etc/inittab file.
wait When the init command enters the run level that matches the entry's run level, start the process and wait for its termination. All subsequent reads of the /etc/inittab file, while the init command is in the same run level, will cause the init command to ignore this entry.
once When the init command enters a run level that matches the entry's run level, start the process, and do not wait for termination. When it dies, do notrestart the process. When the system enters a new run level, and the process is still running from a previous run level change, the program will not be restarted.
boot Process the entry only during system boot, which is when the init command reads the /etc/inittab file during system startup. Start the process, do not wait for its termination, and when it dies, do not restart the process. In order for the instruction to be meaningful, the run level should be the default or it must match the init command's run level at boot time. This action is useful for an initialization function following a hardware reboot of the system.
bootwait Process the entry the first time that the init command goes from single-user to multi-user state after the system is booted. Start the process, wait for its termination, and when it dies, do not restart the process. If the initdefault is 2, run the process right after boot.
powerfail Execute the process associated with this entry only when the init command receives a power fail signal ( SIGPWR).
powerwait Execute the process associated with this entry only when the init command receives a power fail signal (SIGPWR), and wait until it terminates before continuing to process the /etc/inittab file.
off If the process associated with this entry is currently running, send the warning signal (SIGTERM), and wait 20 seconds before terminating the process with the kill signal (SIGKILL). If the process is not running, ignore this entry.
ondemand Functionally identical to respawn, except this action applies to the a, b, or c values, not to run levels.
initdefault An entry with this action is only scanned when the init command is initially invoked. The init command uses this entry, if it exists, to determine which run level to enter initially. It does this by taking the highest run level specified in the run-level field and using that as its initial state. If the run level field is empty, this is interpreted as 0123456789. therefore, the init command enters run level 9. Additionally, if the init command does not find an initdefault entry in the /etc/inittab file, it requests an initial run level from the user at boot time.
sysinit Entries of this type are executed before the init command tries to access the console before login. It is expected that this entry will only be used to initialize devices on which the init command might try to ask the run level question. These entries are executed and waited for before continuing.
Command A shell command to execute. The entire command field is prefixed with exec and passed to a forked sh as sh -c exec command. Any legal sh command syntax can appear in this field. Comments can be inserted with the # comment syntax.
The getty command writes over the output of any commands that appear before it it in the /etc/inittab file. To record the output of these commands to the bootlog, pipe their output to the alog -tboot command. The stdin, stdout, and stderr file descriptors may not be available while the init command is processing inittab entries. Any entries writing to stdout or stderr may not work predictably unless they redirect their output to a file or to /dev/console. The following commands are the only supported methods for modifying the records in the /etc/inittab file.
lsitab Lists records in the /etc/inittab file. mkitab Adds records to the /etc/inittab file. chitab Changes records in the /etc/inittab file. rmitab Removes records from the /etc/inittab file.
Eg:
If you want to add a record on the /etc/inittab file to run the find command on the run level 2 and start it again once it has finished:
1. Run the ps command and display only those processes that contain the word find: # ps -ef | grep find root 19750 13964 0 10:47:23 pts/0 0:00 grep find # 2. Add a record named xcmd on the /etc/inittab using the mkitab command: # mkitab "xcmd:2:respawn:find / -type f > /dev/null 2>&1" 3. Show the new record with the lsitab command: # lsitab xcmd xcmd:2:respawn:find / -type f > /dev/null 2>&1 # 4. Display the processes: # ps -ef | grep find root 25462 1 6 10:56:58 - 0:00 find / -type f root 28002 13964 0 10:57:00 pts/0 0:00 grep find # 5. Cancel the find command process: # kill 25462 6. Display the processes: # ps -ef | grep find root 23538 13964 0 10:58:24 pts/0 0:00 grep find root 28966 1 4 10:58:21 - 0:00 find / -type f #
Since the action field is configured as respawn, a new process (28966 in this example) is started each time its predecessor finishes. The process will continue re-spawning, unless you change the action field,
Eg:
1. Change the action field on the record xcmd from respawn to once: # chitab "xcmd:2:once:find / -type f > /dev/null 2>&1" 2. Display the processes: # ps -ef | grep find root 20378 13964 0 11:07:20 pts/0 0:00 grep find root 28970 1 4 11:05:46 - 0:03 find / -type f 3. Cancel the find command process: # kill 28970 4. Display the processes: # ps -ef | grep find root 28972 13964 0 11:07:33 pts/0 0:00 grep find #
To delete this record from the /etc/inittab file, you use the rmitab command.
Eg:
# rmitab xcmd # lsitab xcmd #
Order of the /etc/inittab entries
The base process entries in the /etc/inittab file is ordered as follows:
The System Resource Controller (SRC) has to be started near the begining of the etc/inittab file since the SRC daemon is needed to start other processes. Since NFS requires TCP/IP daemons to run correctly, TCP/IP daemons are started ahead of the NFS daemons. The entries in the /etc/inittab file are orderedaccording to dependencies, meaning that if a process (process2) requires that another process (process1) be present for it to operate normally, then an entry for process1 comes before an entry for process2 in the /etc/inittab file.
Rom the moment a user turns on a Mac OS X system to beyond the time the login window appears, Mac OS X executes a boot sequence that readies the system for use. If you provide system services to all users, you might need to execute some code during this process. The following sections explain the basic boot sequence and the places where your code can tie into it.
BootROM
When the power to a Macintosh computer is turned on, the BootROM firmware is activated. BootROM (which is part of the computer’s hardware) has two primary responsibilities: it initializes system hardware and it selects an operating system to run. BootROM has two components to help it carry out these functions:
·POST (Power-On Self Test) initializes some hardware interfaces and verifies that sufficient memory is available and in a good state.
·On PowerPC-based Macintosh computers, Open Firmware initializes the rest of the hardware, builds the initial device tree (a hierarchical representation of devices associated with the computer), and selects the operating system to use.
On Intel-based Macintosh computers, EFI does basic hardware initialization and selects which operating system to use.
If multiple installations of Mac OS X are available, BootROM chooses the one that was last selected by the Startup Disk System Preference. The user can override this choice by holding down the Option key while the computer boots, which causes Open Firmware or EFI to display a screen for choosing the boot volume. Note: On some legacy hardware, the same version of BootROM can start either Mac OS 9 or Mac OS X. Most current hardware can start only Mac OS X.
BootX, boot.efi, and System Initialization
Once BootROM is finished and a Mac OS X partition has been selected, control passes to the BootX (PowerPC) or boot.efi (Intel) boot loader. The principal job of this boot loader is to load the kernel environment. As it does this, the boot loader draws the “booting” image on the screen.
BootX and boot.efi can be found in the /System/Library/CoreServices directory on the root partition. In addition, a copy of boot.efi can be found at /usr/standalone/i386/boot.efi.
In "exotic” boot situations such as booting from a software RAID volume, a copy of the boot loader is stored on a separate HFS+ “helper” volume to get the system started. In some versions of Mac OS X, a copy of the kernel and mkext cache are also included on the helper volume. In these cases, the booter and other components on the root volume are unused. Note: Booting from a UFS volume is deprecated as of Mac OS X v10.5.
The boot loader first attempts to load a prelinked version of the kernel that includes all device drivers that are involved in the boot process. This prelinked kernel is located in /System/Library/Caches/com.apple.kernelcaches. By linking these drivers into the kernel ahead of time, boot time is reduced.
If the prelinked kernel is missing, out-of-date, or corrupt, the boot loader attempts to load that same set of device drivers all at once in the form of a single, compressed archive called an mkext cache.
If this cache is also out-of-date, missing, or corrupt, the boot loader searches /System/Library/Extensions for drivers and other kernel extensions whose OSBundleRequired property is set to a value appropriate to the type of boot (for example, local or network boot).
For more information on how drivers are loaded, see I/O Kit Fundamentals.
Once the kernel and all drivers necessary for booting are loaded, the boot loader starts the kernel’s initialization procedure. At this point, enough drivers are loaded for the kernel to find the root device. Also from this point, on PowerPC-based Macintosh computers, Open Firmware is no longer accessible (quiesced).
The kernel initializes the Mach and BSD data structures and then initializes the I/O Kit. The I/O Kit links the loaded drivers into the kernel, using the device tree to determine which drivers to link. Once the kernel finds the root device, it roots(*) BSD off of it. Note: As a terminology aside, the term “boot” was historically reserved for loading a bootstrap loader and kernel off of a disk or partition. In more recent years, the usage has evolved to allow a second meaning: the entire process from initial bootstrap until the OS is generally usable by an end user. In this case, the term is used according to the former meaning.
As used here, the term “root” refers to mounting a partition as the root, or top-level, filesystem. Thus, while the OS boots off of the root partition, the kernel roots the OS off of the partition before executing startup scripts from it.
Prior to Mac OS X v10.4, the remaining system initialization was handled by the mach_init and init processes. During the course of initialization, these processes would call various system scripts (including /etc/rc), run startup items, and generally prepare the system for the user. While many of the same scripts and daemons are still run, the mach_init and init processes have been replaced by launchd in Mac OS X v10.4 and later. This change means that launchd is now the root system process.
In addition to initializing the system, the launchd process coordinates the launching of system daemons in an orderly manner. Like the inetd process, launchd launches daemons on-demand. Daemons launched in this manner can shut down during periods of inactivity and be relaunched as needed. (When a subsequent service request comes in, launchd automatically relaunches the daemon to process the request.)
This technique frees up memory and other resources associated with the daemon, which is worthwhile if the daemon is likely to be idle for extended periods of time. More importantly, however, this guarantees that runtime dependencies between daemons are satisfied without the need for manual lists of dependencies.
Next, launchd starts SystemStarter, which starts any non-launch-on-demand daemons. Note: While launchd does support non-launch-on-demand daemons, this use is not recommended. The launchd daemon was designed to remove the need for dependency ordering among daemons. If you do not make your daemon be launch-on-demand, you will have to handle these dependencies in another way, such as by using the legacy startup item mechanism.
For more information about launch-on-demand and SystemStarter daemons and how to launch them, see “Daemons.”
As the final part of system initialization, launchd launches loginwindow. The loginwindow program controls several aspects of user sessions and coordinates the display of the login window and the authentication of users. Note: By default, Mac OS X boots with a graphical boot screen. For debugging the boot process, it is often useful to disable this, revealing the text console underneath. This mode is known as verbose boot mode. To enable verbose boot mode, simply hold down command-v after the boot chime.
Authenticating Users
Mac OS X requires users to authenticate themselves prior to accessing the system. The loginwindow program coordinates the visual portion of the login process (as manifested by the window where users enter name and password information) and the security portion (which handles the user authentication). Once a user is authenticated by the security systems, loginwindow begins setting up the user environment.
In two key situations, loginwindow bypasses the usual login prompt and begins the user session immediately. The first situation occurs when the system administrator has configured the computer to automatically log in as a specified user. The second occurs during software installation when the installer program is to be launched immediately after a reboot.
Configuring User Sessions
Immediately after the user is successfully authenticated, loginwindow sets up the user environment and records information about the login. As part of this process, it performs the following tasks:
·Secures the login session from unauthorized remote access. Applications that are launched remotely are not registered with the pasteboard server’s (Clipboard’s) port. As a result, some standard features are blocked for these processes, including copy, cut, paste, Apple events, window minimization, and other services.
·Records the login in the system’s utmp database.
·Sets the owner and permissions for the console terminal.
·Resets the user’s preferences to include global system defaults.
·Registers the pasteboard server (pbs) with the bootstrap port and launches pbs.
·Configures the mouse, keyboard, and system sound using the user’s preferences.
·Sets the user’s group permissions (gid).
·Retrieves the user record from Directory Services and applies that information to the session.
·It loads the user’s computing environment (including preferences, environment variables, device and file permissions, keychain access, and so on).
·It launches the Dock, Finder, and SystemUIServer.
·It automatically launches applications specified in the Login Items pane of the Accounts System Preferences for the user.
Once the user session is up and running, loginwindow monitors the session and user applications in the following ways:
·It manages the logout, restart, and shutdown procedures. See “Logout Responsibilities” for more information.
·It manages the Force Quit window, which includes monitoring the currently active applications and responding to user requests to force-quit applications and relaunch the Finder. (Users open this window from the Apple menu or by pressing Command-Option-Escape.)
·It writes any standard-error (stderr) output to a log file. Log files are stored in the /Library/Logs/Console//console.log file, where is the user ID of the currently logged in user.
If the Finder, Dock, or SystemUIServer processes die for some reason, loginwindow automatically restarts them. In the same manner, if the loginwindow process dies, the launchd process automatically restarts it.
Logout Responsibilities
The procedures for logging out, restarting the system, or shutting down the system have similar semantics. The foreground process usually initiates these procedures in response to the user choosing an item from the Apple menu; however, a process can also initiate the procedure programmatically by sending an appropriate Apple event to loginwindow. The loginwindow program carries out the procedure, posting alerts and notifying applications to give them a chance to clean up before closing.
A typical logout/restart/shutdown procedure is as follows:
1.The user selects Log Out, Restart, or Shut Down from the Apple menu.
2.The foreground application initiates the user request by sending an Apple event to loginwindow. (See “Application Responsibilities” for a list of events.)
3.The loginwindow program displays an alert to the user asking for confirmation of the action.
4.If the user confirms the action, loginwindow sends a Quit Application Apple event (kAEQuitApplication) to every foreground and background user process.
5.Once all processes have quit, loginwindow closes out the user session and continues with the action.
oFor a logout action, loginwindow dequeues all events in the event queue, starts the logout-hook program (if one is defined), records the logout, resets device permissions and user preferences to their defaults, and quits. It is subsequently relaunched by launchd to handle a new login. (See “Customizing Login and Logout” for more on loginwindow hooks.)
oFor a restart action, loginwindow sets the device permissions and user preferences to their defaults and then restarts the system.
oFor a shutdown action, loginwindow powers off the system.
Foreground processes can choose not to terminate when they receive the Quit Application event. See “Terminating Processes” for more information.
Application Responsibilities
To initiate a logout, restart, or shutdown sequence programmatically, the foreground application must send an appropriate Apple event to loginwindow. Upon receipt of the event, loginwindow begins the process of shutting down the user session. Depending on the Apple event sent by the process, loginwindow may or may not post an alert dialog and give the user a chance to abort the sequence.
The following list shows the preferred Apple events for logout, restart, and shutdown procedures. These events have no required parameters.
·kAELogOut
·kAEShowRestartDialog
·kAEShowShutdownDialog
Upon receipt of one of these events, loginwindow displays an alert notifying the user of the impending action. At this point, the user may continue with the action or abort it. If the user continues with the action, loginwindow sends an Apple event to each application asking it to quit. See “Terminating Processes.”
In addition to the preferred Apple events, there are two additional events that tell loginwindow to proceed immediately with a restart or shutdown sequence:
·kAERestart
·kAEShutDown
These events proceed with the corresponding sequence without posting an alert dialog to the user. Thus, if you send one of these events to loginwindow, the user does not have an opportunity to abort the sequence. These events should be used sparingly, if at all. Important: Note that if a logout, restart, or shutdown event originates from an application in the Classic environment, the event affects only the Classic environment and its applications. The rest of the user session continues running.
Terminating Processes
As part of a log out, restart, or shutdown sequence, loginwindow attempts to terminate all foreground and background user processes. It sends each process a Quit Application Apple event (kAEQuitApplication), as a courtesy, to give each process a chance to shut itself down gracefully. For foreground processes, loginwindow sends the event and waits for a reply. For background processes, loginwindow sends the event but does not wait for a reply. It terminates any lingering background processes by sending a kill command.
When a foreground process receives the Quit Application Apple event from loginwindow, it should terminate itself immediately or post an alert dialog if a user decision is required first (such as when there is an unsaved document); when that condition is resolved the application should then terminate. If the user decides to abort the termination sequence (by clicking Cancel in a Save dialog, for example) the application should respond to the event by returning a userCancelledErr error. Note: Cocoa applications do not see the kAEQuitApplication event directly. The Application Kit notifies your application by calling its applicationShouldTerminate: delegate method. To abort the termination sequence, implement this method and return NSTerminateCancel; otherwise, termination of your application continues normally.
If a foreground application fails to reply or terminate itself after 45 seconds, loginwindow automatically aborts the termination sequence. This safeguard is to protect data in various situations, such as when an application is saving a large file to disk and is unable to terminate in the allotted time. If a foreground application is unresponsive and not doing anything, the user must use the Force Quit window to kill it before proceeding.
For user background processes that link with Carbon, Cocoa, or Java, the procedure is a little different. The loginwindow program notifies the process that it is about to be terminated by sending it a Quit Application Apple event (kAEQuitApplication) as before. Unlike foreground processes, however, loginwindow does not wait for a reply. It proceeds to terminate any open background processes, regardless of any returned errors.
During a user logout, loginwindow does not terminate processes residing in the root context. These processes reside outside the context of the user session and are terminated only during a restart or shutdown sequence. The loginwindow program also does not kill background processes that are independent of Carbon, Cocoa, or Java, even if they are launched from the user context. (Though launched from a user context, these processes are taken over by the system when the user logs out.) Mac OS X does not send any notifications to system processes before terminating them.
Identifying the Scope of Processes
Although the launchd process owns every other process on the system, a distinction can still be made between user and system processes. Startup items, daemonized processes, and any processes run prior to loginwindow typically run in the root context. Processes in this context provide services to all users of the system.
Processes that run within the context of an authenticated user session are user processes. User processes are always associated with a particular user session and are usually children of the WindowServer or loginwindow processes associated with the user login. Note: Not all user processes are children of the WindowServer process. Processes launched as root, and some special system processes, are owned by the user but are children of the launchd process. You can use the ActivityMonitor application to determine the owner and parent of any process on the system.
The Shutdown Process
At shutdown, Mac OS X first executes the service stop routines in any SystemStarter startup items such as those described in “Creating a Startup Item.”
Next, as with most UNIX-based and UNIX-like operating systems, Mac OS X sends a SIGTERM signal to all running processes prior to shutdown. Upon receiving this signal, your daemon should quickly make an orderly shutdown.
Every reasonable attempt will be made to wait for it to exit, but it is ultimately the responsibility of your daemon to keep the amount of unsaved state information to a level that can be reasonably written to disk in the time allotted.
A few seconds later, your daemon will receive a SIGKILL signal and will be terminated.
Understanding the booting process is important in the sense that you can get a clear idea when a system faces a booting problem if you are familiar with the booting sequence and steps involved. You can thereby isolate a booting phase and quickly resolve the issues.
Booting process in Solaris can be divided in to different phases for ease of study . First phase starts at the time of switching on the machine and is boot prom level , it displays a identification banner mentioning machine host id serial no , architecture type memory and Ethernet address This is followed by the self test of various systems in the machine.
This process ultimately looks for the default boot device and reads the boot program from the boot block which is located on the 1-15 blocks of boot device. The boot block contains the ufs file system reader which is required by the next boot processes.
The ufs file system reader opens the boot device and loads the secondary boot program from /usr/platform/`uname –i`/ufsboot ( uname –i expands to system architecture type)
The boot program above loads a platform specific kernel along with a generic solaris kernel
The kernel initialize itself and load modules which are required to mount the root partition for continuing the booting process.
The booting process undergoes the following phases afterwards :
1) init phase
2) inittab file
3) rc scripts & Run Level
1. INIT phase
Init phase is started by the execution of /sbin/init program and starts other processes after reading the /etc/inittab file as per the directives in the /etc/inittab file .
Two most important functions of init are
a) It runs the processes to bring the system to the default run level state ( Run level 3 in Solaris , defined by initdefault parameter in /etc/inittab )
b) It controls the transition between different run levels by executing appropriate rc scripts to start and the stop the processes for that run level.
2. /etc/inittab file
This file states the default run level and some actions to be performed while the system reaches up to that level. The fields and their explanation are as follows :
The complete line thus means run the command /sbin/rc3 at run level 3 and wait until the rc3 process is complete.
The action field can have any of the following keywords :
Initdefault : default run level of the system
Respawn : start and restart the process if it stops.
Powerfail : stop on powerfail
Sysinit : start and wait till console in accessible .
Wait : wait till the process ends before going on to the next line.
3. RC scripts & Run Levels
Rc scripts performs the following functions :
a) They check and mount the file systems
b) Start and stop the various processes like network , nfs etc.
c) Perform some of the house keeping jobs.
System goes in to one of the following run level after booting depending on default run level and the commands issued for changing the run level to some other one.
0 Boot prom level ok> or > prompt in Sun.
1 Administrative run level . Single user mode
2 Multiuser mode with no resource sharing .
3 Multiuser level with nfs resource sharing
4 Not used
5 Shutdown & power off (Sun 4m and 4u architecture )
6 Reboot to default run level
S s Single user mode user logins are disabled.
Broadly speaking the running system can be in any of the folloing state
Single user – Minimum processes running , user logins disabled and root password is required to gain access to the shell .
Multiuser - All system processes are running and user logins are permitted
Run level of a desired state is achieved by a number of scripts executed by the rc program the rc scripts are located in /etc/rc0.d , /etc/rc1.d , /etc/rc2.d , /etc/rc3.d & /etc/rcS.d directories . All the files of a particular run level are executed in the alphanumeric order .Those files beginning with letter S starts the processes and those beginning with K stops the processes.
These files are hard linked to the files in /etc/init.d in order to provide a central location for all these files and eliminating the need to change the run level in case these scripts needs to be run separately . The files in /etc/init.d directory are without any S , K and numeric prefix instead a stop / start argument has to be supplied whenever these scripts are to be executed .
By default system has a number of rc scripts needed for run level transition but sometimes it becomes necessary to start some custom scripts at the booting time and turn them off at the shutdown . Custom scripts can be put in any of the required rc directory but following major considerations has to be kept in mind :
* The sequence number of the file should not conflict with other files.
* The sevices needed should be available by previously executed scripts.
* File should be hard linked to the /etc/init.d directory .
* The system looks for only those files beginning with letter K & S , any thing else is ignored , therefore, to make a file inactive simply changing uppercase K or S to lower case will cause system to ignore it .
