When the computer is powered up, the firmware is in complete control. After the firmware initializes the hardware, it hands off control to the BootX loader, which bootstraps the kernel. After a trip into Mach, the control bubbles up into the BSD subsystem, and eventually into the Aqua user interface.
By default, Mac OS X boots graphically. If you'd like to see console messages as you boot, hold down -V (the "V" stands for "verbose") as you start the computer. If you'd like to always boot in verbose mode , you can specify a flag in the boot arguments that are stored in your system's firmware. First, use the command nvram boot-args to make sure there aren't any flags already set (if there are, and you didn't set them, you probably should not change this setting). Set your boot arguments to -v with this command:
sudo /usr/sbin/nvram boot-args="-v"
The next time you boot your Mac, it boots in verbose mode. To turn this setting off, use the command:
sudo /usr/sbin/nvram boot-args=
To boot in single-user mode , hold down -S as you start the computer. In single-user mode, your filesystem is mounted as read-only, which limits what you can do. Single-user mode should generally be used only to repair a system that has been damaged (for example, see "Restoring the Directory Services Database" in Chapter 5). Unlike with other Unix systems, we do not suggest that you use single-user mode to perform fsck repairs manually. Instead, restart your Mac and boot from Tiger's install DVD (hold down the C key as your Mac starts up), and then run the Disk Utility (Installer Open Disk Utility) to repair a problem disk volume.
4.1.1. The BootX Loader
BootX is located in /System/Library/CoreServices. It draws the Apple logo on the screen and proceeds to set up the kernel environment. BootX first looks for kernel extensions (drivers , also known as kexts) that are cached in the mkext cache. If this cache does not exist, BootX loads only those extensions in /System/Library/Extensions that have the OSBundleRequired key in their ExtensionName.kext/ Info.plist file. Example 4-1 is an excerpt from the /System/Library/Extensions/System.kext/Info.plist file.
Example 4-1. A portion of a kernel extension's Info.plist file
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>English</string> <!-- multiple keys and strings omitted --> </dict> </plist>
After the required drivers are loaded, BootX hands off control to the kernel (/mach_kernel).
The kernel first initializes all the data structures needed to support Mach and BSD. Next, it initializes the I/O Kit, which connects the kernel with the set of extensions that correspond to the machine's hardware configuration. Then, the kernel finds and mounts the root filesystem. The kernel then launches the first process on the system, launchd , which is responsible for bootstrapping the system as well as launching daemons on behalf of the system or users.
Mac OS X Panther (10.3) and earlier did things differently. The first process the kernel loaded was mach_init, which started Mach message handling. mach_init then launched the BSD init process. In keeping with Unix conventions, init was process ID (PID) 1, even though it was started second. mach_init was given PID 2, and its parent PID was set to 1 (init's PID). As of Mac OS X Tiger (10.4), launchd replaces both of these processes.
4.1.3. The /etc/rc Script
If you're booting normally, launchd loads the /etc/rc shell script to start the system (if you're booting in single user mode, /etc/rc is not run at all). This rc script sources the /etc/rc.common script, which sets the initial environment, defines some common functions, and loads the /etc/hostconfig file, which controls the system services that get started at boot. Example 4-2 is an excerpt from the hostconfig file.
Example 4-2. A portion of /etc/hostconfig
# Services AFPSERVER=-NO- CUPS=-AUTOMATIC-
This excerpt shows the settings that determine whether Apple File Sharing and CUPS (Common Unix Printing System) are launched at startup. See "The startup script" later in this chapter, for an explanation of how /etc/hostconfig can be used to control services that you install yourself. Table 4-1 describes the default entries from /etc/hostconfig.
Table 4-1. Default entries from the hostconfig file
Specifies a hostname. A setting of -AUTOMATIC- causes configd to use the value from the system configuration database.
This specifies the default router. -AUTOMATIC- causes Mac OS X to use the router supplied by DHCP or BOOTP. The settings in System Preferences Network override this.
Controls whether Apple File Sharing (Personal File Sharing in System Preferences Sharing) is enabled. This corresponds to the AppleShare startup item. (For information on startup items, see "SystemStarter," later in this chapter.)
Specifies whether the NetInfo authentication server for legacy clients (/usr/sbin/tim) should be started. This corresponds to the AuthServer startup item.
Determines whether the NFS automount daemon should be started. The NFS startup item consults this setting.
Controls whether Printing Services are started up. This corresponds to the PrintingServices startup item. However, this is not controlled by the Printer Sharing option in System Preferences Sharing (that setting instead inserts the appropriate settings into the /etc/cups/cupsd.conf file).
Determines whether the Network startup item enables IP forwarding.
Specifies whether the Network startup item should turn on IPv6 support.
If your Mac is running as an NFS server, a setting of -AUTOMATIC- enables locking for NFS files. As an NFS client, a value of -YES- enables locking, but -AUTOMATIC- loads the appropriate daemons (rpc.statd and rpc.lockd) so they are only used when needed. The NFS startup item consults this setting.
Specifies the NIS Domain that your Mac should participate in. Leave it set to -NO- to disable NIS, otherwise set it to the appropriate domain. The NIS startup item uses this setting.
Controls whether the network time daemon (ntpd) is started. You can configure these settings with System Preferences Date & Time. This setting affects the NetworkTime startup item.
Specifies whether the QuickTime Streaming Server is started at boot time. Although it's not included with the desktop version of Mac OS X, you can download it from http://developer.apple.com/darwin/projects/streaming/.
Controls whether the Apache web server (Personal Web Sharing in System Preferences Sharing) is started. This corresponds to the Apache startup item.
This setting has no effect. Older versions of Mac OS X used it to control Samba , the Windows file sharing server. This setting can be toggled using Windows Sharing in System Preferences Sharing, which toggles the disable setting in /etc/xinetd.d/smbd.
Specifies whether the SNMP agent is to be started. This corresponds to the SNMP startup item.
Controls whether the crash reporter is started. You can refine the crash reporter settings with /Developer/Utilities/CrashReporterPrefs.
Specifies whether Apple Remote Desktop (also specified in System Preferences Sharing) is started.
After rc has loaded in values from /etc/rc.common and /etc/hostconfig, it performs a check of the filesystem (fsck) if needed. If the fsck fails, rc tries an fsck -fy, which forces a check and assumes a "Yes" answer to all the questions that fsck asks. If that fails, the system halts.
If you find yourself with fsck problems, you should boot from the Mac OS X installation DVD. You can boot from a DVD by holding down the C key at startup. When the Installer appears, choose Installer Disk Utility from the menu bar and use it to inspect and repair the damaged disk.
Next, /etc/rc performs the following steps (among others, that is; this list describes the most significant):
Mounts local filesystems
By this point, the root filesystem is already mounted, but the rc script now mounts any additional HFS+ and UFS volumes listed in /etc/fstab, as well as the /dev filesystem. This step does not, however, perform the automatic mounting of local volumes under the /Volumes directory. This is handled by the disk arbitration daemon, which is started as a Mach bootstrap daemon (see "Mach Bootstrap Services," later in this chapter).
The rc script initializes the boot-time performance cache (BootCacheControl), which implements intelligent read-ahead strategies for the boot volume.
Tunes the system
Next, a series of sysctl calls tune kernel variables such as the maximum number of vnodes (data structures the kernel uses to represent files) and various shared memory settings.
Enables virtual memory
At this point, the dynamic_pager daemon starts running. This daemon manages swap files in the /var/vm/ subdirectory. The kernel uses these files to allocate virtual memory as it is needed.
Starts kextd, the kernel extension daemon
The kernel initially boots with the minimum set of extensions needed to mount the root filesystem on all supported hardware. Some of these extensions are not needed, so /etc/rc starts the kextd daemon (/usr/libexec/kextd) to unload unnecessary extensions. For example, the iPodDriver includes the OSBundleRequired key to support booting from your iPod. If you don't have your iPod plugged in, kextd can safely unload that driver. The kextd daemon is also responsible for loading and unloading extensions on demand for the duration of the system's uptime. Extensions live in the /System/Library/Extensions directory.
Creates the NetInfo Database
NetInfo is a Directory Services database for standalone machines. See Chapter 3 for a complete discussion. In this step, the rc script creates a default NetInfo database (only if none exists).
Launches Mach bootstrap services
Next, the rc script runs register_mach_bootstrap_servers on all the services listed in /etc/mach_init.d. That directory contains a collection of XML .plist files containing a description of services, the path to the corresponding executable, and whether the service should be loaded on demand. See "Mach Bootstrap Services," later in this chapter.
Starts up Launch Daemons
As of Mac OS X 10.4 Tiger, the SystemStarter (see "SystemStarter," later in this chapter) method for starting up daemons is reserved for core system components such as Apache, Spotlight, and Apple Remote Desktop. In its place, launchd, which is also the first process on the system, takes care of bootstrapping most of the services on the system. See "launchd," later in this chapter.
Sets the system language
If this system is not fully configured (if the file /var/db/.AppleSetupDone does not exist), the language chooser appears at this point and prompts the user to choose a default language for the system. Whether that chooser appears, the rc script reads in /var/log/CDIS.custom and exports the variable it contains into subsequent environments.
After these steps are completed, /etc/rc hands off control to /sbin/SystemStarter, which is described in the "SystemStarter" section later in this chapter.
It's true there are three ways to start a daemon on Mac OS X: using SystemStarter, Mach Bootstrap Services, and launchd. Of the three of these, launchd is the latest, but for some purposes, you'll find the SystemStarter scheme to be best. For more information, see "SystemStarter" and "Adding Startup Items," later in this chapter.
4.1.4. Mach Bootstrap Services
Mac OS X Panther introduced Mach bootstrap services, a new approach for starting daemons. Daemons can be loaded at two points: system startup and user login, which includes local and remote (such as SSH) logins. System startup scripts go into /etc/mach_init.d, and user login scripts go into /etc/mach_init_per_user.d. Bootstrap daemons are identified to the system using the ServiceName in their .plist files, and the operating system can load that service on demand if the OnDemand option is set to true (this is the default). Mac OS X will launch these services on demand or wake sleeping bootstrap services (when a bootstrap service goes unused for a period of time, it can sleep). Table 4-2 describes the services started in this stage.
Table 4-2. Mach bootstrap services
Launches the Apple Type Solution server.
Starts the Configuration server daemon. See "scutil" in Chapter 17 for information on working with the Configuration server's database.
Starts the Core Audio daemon.
Launches the Core Services daemon.
Starts The DirectoryService daemon. For more information, see Chapter 5 and the DirectoryService manpage.
Launches the disk arbitration daemon, which coordinates the mounting of filesystems. For more information, see the diskarbitrationd manpage.
Starts the distributed notifications daemon.
Unknown or undocumented.
Starts a daemon required to support iSight audio.
Configures the single sign-on service. See the kerberosautoconfig manpage .
Starts the Kernel-User Notification daemon, which kernel-level code can use to pop up dialogs when user action is needed. See the "Kernel-User Notification" topic in Writing an I/O Kit Device Driver, which you can find at http://developer.apple.com/documentation/DeviceDrivers/.
Starts lookupd, a thin layer that acts as a frontend to Directory Services. For more information, see the lookupd manpage and Chapter 5.
Starts the mds daemon used by Spotlight.
Starts the group membership daemon.
Launches the server for the Mac OS X notification system. For more information, see the notify(3) manpage.
Starts the Online Certificate Status Protocol daemon, used to check the status of a certificate.
Launches a daemon used by the SCSI subsystem.
Starts the security server, which manages keychain items and other cryptographic operations.
Starts the Mac OS X WindowServer, the service that manages the screen and the windows drawn upon it.
Mac OS X Tiger introduces the latest and greatest startup scheme, launchd . It has launch-on-demand capabilities and also supports on-demand launching via Mach ports (as does the mach_init.d scheme). launchd also offers the ability to launch on demand based on file system and Unix domain socket events. The property list (.plist) files for system-installed daemons are in /System/Library/LaunchDaemons. Locally-installed daemons can be installed into /Library/LaunchDaemons. Table 4-3 lists and describes the system-installed daemons, most of which have counterparts in Linux and Unix systems.
For an example of a launch daemon property list, see "Periodic Jobs," later in this chapter.
You can control launch daemons with the launchctl utility. For example, to enable and load a daemon that's disabled (there will be a Disabled key in its property list file), use launchctl load -w followed by the path to the property list. For example, the following command would enable and start the telnet server:
# launchctl load -w /System/Library/LaunchDaemons/telnet.plist
You can stop and disable this daemon with unload -w:
# launchctl unload -w /System/Library/LaunchDaemons/telnet.plist
For more information, see the launchctl manpage.
Table 4-3. Default Mac OS X launch daemons
Property List File
Enabled by default?
Starts the DHCP/BOOTP daemon.
Launches the atrun daemon.
Runs the kernel event agent, which responds to low-level kernel events (such as disk and network events).
Starts the Multicast DNS responder, needed by Bonjour.
Launches the NetInfo binder daemon.
Runs the daily periodic job.
Runs the monthly periodic job.
Runs the weekly periodic job.
Starts the portmapper.
Launches the system log daemon.
Runs the Xgrid agent.
Runs the Xgrid controller.
Starts the cron daemon.
Runs the Apple Events server.
Starts rexecd, the remote execution server.
Launches the finger daemon.
Starts the FTP server.
Starts the remote login (rlogin) daemon.
Launches Samba's nmbd daemon.
Starts the ntalk daemon.
Launches the postfix master process.
Starts the Internet superserver (xinetd).
Starts the CUPS lpd server.
Starts the remote shell daemon (rshd).
Launches Samba's smbd daemon.
Starts the SSH server.
Runs the Samba Web Administration Tool.
Launches the telnet server.
Starts the Trivial FTP server daemon.
SystemStarter examines /System/Library/StartupItems and /Library/StartupItems for applications that should be started at boot time. /Library/StartupItems contains items for locally installed applications. /System/Library/StartupItems contains items for the system. You should not modify these or add your own items here. Table 4-4 lists Mac OS X's available startup items.
Because much of SystemStarter's responsibilities have been handled by launchd, the number of startup items has dramatically decreased since Mac OS X 10.3.
Table 4-4. Mac OS X default startup items
Starts the Apache web server. Enable this with the WEBSERVER entry in/etc/hostconfig or by turning on Web Sharing (System Preferences Sharing).
Starts the desktop database, input managers, and printing services.
Starts Apple file sharing. Enable this with the AFPSERVER entry in /etc/hostconfig or by turning on File Sharing (System Preferences Sharing).
Starts the authentication server. Enable this with the AUTHSERVER enTRy in /etc/hostconfig.
Enables automatic crash report generation when an application crashes. Enable this with the CRASHREPORTER entry in /etc/hostconfig.
Mounts local filesystems.
Starts support for Fibre Channel controllers.
Launches ifcstart, which is used for international components of Mac OS X.
Starts xinetd and, optionally, Internet address sharing.
Launches the daemons required for Spotlight.
Starts the NFS client. The NFS server is started if NetInfo or /etc/exports has been configured to export one or more filesystems.
Starts the Network Information Service unless NISDOMAIN is set to -NO in /etc/hostconfig.
Starts the NTP client. Enable this with the TIMESYNC enTRy in /etc/hostconfig or with System Preferences Date & Time.
Starts the Common Unix Printing System (CUPS).
Starts the remote desktop server. Enable it with the ARDAGENT entry in /etc/hostconfig or by enabling Apple Remote Desktop in System Preferences Sharing.
Starts snmpd, the SNMP daemon. Enable it with the SNMPSERVER enTRy in /etc/hostconfig.
4.1.7. The Login Window
Once SystemStarter is finished, getty is launched. In /etc/ttys, the console entry launches the Login Window (/System/Library/CoreServices/loginwindow.app ). At this point, the system is fully functional and ready to accept logins.