Section 5.2. The Operating System Boot Process


5.2. The Operating System Boot Process

When Open Firmware boots Mac OS X, it does so through BootX (located in /System/Library/CoreServices). It's important to note that Open Firmware doesn't know that it's booting Mac OS X, nor does it have any concept of the filesystem that contains BootX. All it knows is that there is a program at a particular location on a drive that it can load and run. It is the job of BootX to boot the system from there.

The first thing BootX does is display the "boot" image on screen. This is the monochrome gray-on-gray screen with the Apple logo and spinner on it that you see after your computer chimes. It then loads the kernel from the disk and the essential kernel-level device drivers (such as those for accessing disk drives) necessary to get things running. Once loaded, the kernel's initialization procedure is called.

The kernel loads device drivers for all the devices connected to the computer and then finds the boot drive. It may seem a bit odd that the kernel has to find the drive that it was loaded from, but remember that it was loaded from the drive and then started. The kernel determines the drive it was loaded from by consulting Open Firmware. Once the kernel finds the boot drive, it mounts the drive at the Unix filesystem root (/), starts its internal process server, which allows processes to communicate with each other, and then starts the launchd daemon, which takes over for the BSD /sbin/init program previously used by earlier versions of Mac OS X.

5.2.1. Launch Control

Prior to Tiger, Mac OS X used a very traditional Unix startup process. After initialization, the kernel would load mach_init and init before passing control to the /etc/rc script. The rc script did the bulk of preparing your Mac for everyday use, and it continues to on Tiger. It starts the virtual memory system, mounts filesystems, loads kernel extensions, and launches service daemons. Finally, pre-Tiger Macs would launch SystemStarter to finish booting the system.

For Tiger, Apple reinvented Mac OS X's startup procedure. However, the repercussions of these changes extend beyond the boot process . On a Unix system, there are several daemons tasked with launching other applications. Some of these "super daemons," like xinetd and inetd, launch a daemon in response to a network connection. Others, like cron and at, run software based on time schedules. Tiger's launchd replaces not only init and SystemStarter, but these other daemons as well.

When loaded by the kernel, launchd scans through /System/Library/LaunchDaemons and /Library/LaunchDaemons for items that need to be loaded. Like SystemStarter before it, launchd uses XML-formatted property list (plist) files to store configuration information for each daemon. Using these files, launchd determines which services are enabled, their dependencies, and whether they can be launched on demand. Next, launchd loads the services in an order that satisfies all dependencies and, when possible, uses parallel execution. This allows Tiger to load what it needsand only what it needsas quickly as possible, resulting in shorter boot times and a leaner system.

5.2.1.1. Daemons and agents

The launchd daemon breaks background processes into two types: agents and daemons . An agent is an application that runs within the context of a user session. That is, it is designed to stay in the background and handle requests for the length of a user's use of the system. When the user logs in, the agent is started. When he logs out, the agent is stopped. A daemon, by contrast, is designed to provide services for the entire time the system is running, regardless of which user is logged in; daemons are started at boot and stopped at shutdown. In short, agents are for users, daemons are for the system.

launchd is capable of handling both daemons and agents. On Tiger, the majority of system services that were formerly started by SystemStarter have been migrated to use launchd. In addition, services and tasks started by xinetd and cron have also been migrated. Though Mac OS X is the only Unix system to use this new launcher so far, Apple has made launchd open source, paving the way for adoption by other Unix systems. Apple also plans to extend launchd to handle other types of launch tasks. For example, a future version of launchd could sense hardware changes and load an application in response, similar to how plugging in a digital camera launches iPhoto with the current system.

5.2.1.2. Inside a launchd property list file

Configuration files for each of the services handled by launchd are kept in either /System/Library/LaunchDaemons or /Library/LaunchDaemons (following the filesystem domains discussed in Chapter 3). Agents keep their configuration files in similar locations, but within a folder named LaunchAgents. Each service's launchd configuration file is an XML-formatted property list similar to that shown in Example 5-5.

Example 5-5. A launchd service property list 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>Label</key>     <string>com.apple.syslogd</string>     <key>ServiceDescription</key>     <string>Apple System Log Daemon</string>     <key>OnDemand</key>     <false/>     <key>ProgramArguments</key>     <array>             <string>/usr/sbin/syslogd</string>     </array>     <key>ServiceIPC</key>     <false/> </dict> </plist>

Example 5-5 shows the property list file for syslogd. Since most of Tiger's services have been configured to work with launchd, you can find a number of other examples in the /System/Library/LaunchDaemons folder.

5.2.1.3. Working with launchd services

To control launchd services by hand, Apple has provided the launchctl command (short for "launch control"). Using launchctl, you can start and stop services, load and unload configuration files, and view running services on your system. Because launchd has been written to handle both user and system daemons and agents, you'll need to call launchctl with root privileges to access services run by the system. Example 5-6 shows how to use launchctl to list launchd's active system services.

Example 5-6. Viewing launchd's active services
 $ sudo launchctl list com.apple.KernelEventAgent com.apple.mDNSResponder com.apple.nibindd com.apple.periodic-daily com.apple.periodic-monthly com.apple.periodic-weekly com.apple.portmap com.apple.syslogd com.vix.cron org.postfix.master org.xinetd.xinetd com.openssh.sshd

5.2.2. SystemStarter

Though launchd is the primary launch mechanism for applications on Tiger, not all daemons and agents have been updated to make use of it. Because of this, you may still end up using SystemStarter to launch custom daemons. SystemStarter determines the services it should start by scanning /System/Library/StartupItems and /Library/StartupItems for items to be started when the system starts up, and then launches them. To help reduce boot time, SystemStarter attempts to run as many startup items as possible in parallel. This means startup tasks that take a little while to complete, such as setting up the network, don't stop all the other startup tasks from starting. This parallel process lets the boot process take advantage of dual processor machines.

5.2.2.1. The hostconfig file

Many startup items need some amount of input as to whether they should be launched or not. For example, if Personal Web Sharing is turned off on your machine, then the Apache startup item should not activate. To control these startup items without moving them out of their StartupItems folder, Mac OS X provides the /etc/hostconfig filea simple file consisting of a set of name-value pairs indicating which services should be run and which ones should not. This file is shown in Example 5-7.

Example 5-7. An example /etc/hostconfig file
 ## # /etc/hostconfig ## # This file is maintained by the system control panels ## # Network configuration HOSTNAME=-AUTOMATIC- ROUTER=-AUTOMATIC- # Services AFPSERVER=-YES- AUTHSERVER=-NO- AUTOMOUNT=-YES- CUPS=-YES- IPFORWARDING=-NO- IPV6=-YES- MAILSERVER=-NO- NETINFOSERVER=-AUTOMATIC- NFSLOCKS=-AUTOMATIC- NISDOMAIN=-NO- RPCSERVER=-AUTOMATIC- TIMESYNC=-YES- QTSSERVER=-NO- WEBSERVER=-NO- SMBSERVER=-NO- DNSSERVER=-NO- COREDUMPS=-NO- VPNSERVER=-NO- CRASHREPORTER=-YES-

By looking at this file, you can see that many of the various servers available on the system aren't started at boot time. If you use the System Preferences application to enable a service and come back to this file, you'll see that the -NO- next to a service name has changed to -YES-.

The SystemStarter doesn't use /etc/hostconfig to make its decisions about which services to start; individual services use this information to decide that for themselves. For example, SystemStarter always runs the RemoteDesktop startup item, but when the RemoteDesktop startup item is invoked, it checks /etc/hostconfig to see whether it should run or not.


5.2.2.2. Anatomy of a startup item

So what does a startup item look like? At a basic level, a startup item is a folder with the name of the startup item that contains the following two files:

  • A program; typically a shell script, whose name matches the name of the startup item.

  • A configuration property list (plist) file named StartupParameters.plist declaring the services provided by the item and its dependencies. Table 5-2 lists the keys that must appear in the configuration property list.

Table 5-2. StartupParameters.plist key descriptions

Key

Description

Description

A short description of the startup item. This string appears in the Boot panel at startup.

Provides

A list of services provided by the startup item. A service typically provides only one kind of service. SystemStarter runs only the first startup item it finds for any service provided.

Requires

A list of the services that this service depends on and that must be started before this item can be started. Note each item on this list must contain the service name, not the startup item name, of the service.

Uses

A list of services that this item uses but that aren't required for this item to be started.

OrderPreference

A string that lets SystemStarter determine in which order to start items that are equal in the dependency tree. This string can be one of the following: "First," "Early," "None," "Late," and "Last." This preference is advisory and might be ignored by SystemStarter.


Creating your own startup item is easy; much easier than actually writing a program that provides a useful service, although simple shell scripts that delete old files are useful services, too. Here's the step-by-step process to create your own startup item:

  1. Create a directory in /Library/StartupItems for your startup item. The name of the directory is the name of the item and should give some clue as to its function. Never create startup items in /System/Library/StartupItemsthat's the domain of Mac OS X.

  2. Create an executable in the directory and name it the same thing as your startup item. The executable can be a shell script or a compiled program.

  3. Create the StartupParameters.plist file in the directory. This file must be a valid property list file and contain values for the Description, Provides, Requires, Uses, and OrderPreference keys. You can create this file either by using a text editor and following the format shown in Example 5-8, or by using the Property List Editor application (/Developer/Applications/Utilities).

Example 5-8. The StartupItems.plist file for the Apache web server
 {     Description = "Apache web server";     Provides = ("Web Server");     Requires = ("DirectoryServices");     Uses = ("Disks", "NFS");     OrderPreference = "None"; }

SystemStarter is not just responsible for starting up startup items; it can also be used to restart or stop them. Because of this, SystemStarter passes in an argument to a startup item's executable, indicating the desired action. The valid strings for this argument are: "start," "restart," or "stop." A startup item is responsible for checking this argument and acting accordingly. Example 5-9 shows a sample startup script that can handle this. You can use this sample script as a template for your own startup items.

Example 5-9. A simple startup item executable
 #!/bin/sh # This script includes the /etc/rc.common file which provides useful # functions that make the job of creating a startup item easier. . /etc/rc.common StartService(  ) {     "Starting my service"     # insert code to start service here. } RestartService(  ) {     ConsoleMessage "Restarting my service"     # insert code to stop service here. } StopService(  ) {     ConsoleMessage "Stopping my service"     # insert code to stop service here. } # This should be the last line of your startup item. It calls the # RunService function defined in rc.common which will in turn call # the appropriate function in this script. RunService "$1"

5.2.2.3. Starting and stopping startup items

You can start and stop Startup Items at any time using the SystemStarter command-line tool. To use this tool, use the following syntax:

 SystemStarter action service

where action is either start, stop, or restart, and service is the kind of service the startup item provides. Example 5-10 shows how to manually start the Apache web server.

Example 5-10. Manually starting the Apache web server
 $ sudo SystemStarter start "Web Server" Starting Apache web server Processing config directory: /private/etc/httpd/users/*.conf  Processing config file: /private/etc/httpd/users/colpanic.conf  Processing config file: /private/etc/httpd/users/jldera.conf  Processing config file: /private/etc/httpd/users/panic.conf /usr/sbin/apachectl start: httpd started

The output from SystemStarter lets you know what's going on. In the case of the example here, the alert indicating that the server's fully qualified domain name couldn't be found is normal. To stop the Apache web server, use the command shown in Example 5-11.

Example 5-11. Manually stopping the Apache web server
 $ sudo SystemStarter stop "Web Server" Stopping Apache web server /usr/sbin/apachectl stop: httpd stopped

5.2.3. Booting into Safe Mode

At some point you may experience a problem with a kernel extension crashing during system startup, which causes a kernel panic before startup is complete. To start your machine and remove or repair the offending item, Mac OS X can be booted into Safe Mode. To boot into Safe Mode, hold down the Shift key as you boot your Mac; this loads only the absolute minimum number of kernel extensions and only the most crucial daemons and services.

Because of Safe Mode's restrictions on kernel extensions and startup items, you are quite limited in what you can do. You can't use a DVD player, capture video, use an AirPort wireless network, or many other things. Therefore you should really use Safe Mode only when you need to troubleshoot a startup issue.




Running Mac OS X Tiger
Running Mac OS X Tiger: A No-Compromise Power Users Guide to the Mac (Animal Guide)
ISBN: 0596009135
EAN: 2147483647
Year: 2004
Pages: 166

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net