launchd

launchd has two main tasks. The first is to boot the system, and the second is to load and maintain services.

Here is a simplified view of the Mac OS X Tiger system startup on a PowerPC Mac (on an Intel Mac, EFI replaces Open Firmware and boot.efi replaces BootX):

1. Open Firmware activates, initializes the hardware, and then loads BootX.
2. BootX loads the kernel, spins the pinwheel cursor, and loads any needed kernel extensions (kexts).
3. The kernel loads launchd.
4. launchd runs /etc/rc, various scripts which scan through /System/Library/LaunchDaemons and /Library/LaunchDaemons, calling launchctl on the plists as needed, then launchd starts the login window.

In step 4, the startup scripts scan through a few different directories for jobs to run. There are two different directories that are scanned:

1. The LaunchDaemons directories contain items that will run as root, generally background processes.
2. The LaunchAgents directories contain jobs, called agent applications, that will run as a user or in the context of userland. These may be scripts or other foreground items, and they can even include a user interface.

These directories are all kept in the typical Library directories of Mac OS X.

launchd is very different from SystemStarter in that it may not actually launch all the daemons at boot time. Key to launchd, and similar to xinetd, is the idea of launch-on-demand daemons. When launchctl scans through the job plists at boot time, it asks launchd to reserve and listen on all of the ports requested by those jobs. If so indicated in the plist by the "OnDemand" key, the daemon is not actually loaded at the time. Rather, launchd will listen on the port, start the daemon when needed, and shut it down when it is no longer needed. After a daemon is loaded, launchd will keep track of it and make sure it is running if needed. In this way it is like watchdogd, and shares watchdogd's requirement that processes do not attempt to fork or daemonize on their own. If a process goes into the background, launchd will lose track of it and attempt to relaunch it.

Mac OS X Tiger, consequently, boots much faster than previous releases. The system only has to register the daemons that are to run and does not actually launch them until they are needed. In fact, the progress bar that appears during boot time is just a placebo application (named WaitingForLoginWindow[1]) that does not really show anything other than the passage of time.

The hardest part to manage during a launchd boot is dependencies. SystemStarter had a very simple system of dependencies that used the "Uses", "Requires", and "Provides" keys in the plist of a startup item. There are two main strategies when creating launchd dependencies on Tiger: IPC allows daemons to talk amongst themselves to work out dependencies, or daemons can watch files or paths for changes. Using IPC is much more subtle than the SystemStarter's keys and requires more work from the developer, but it may lead to cleaner and quicker startups. SystemStarter was still supported up to OS X Mountain Lion, but was removed in OS X Yosemite.

In launchd, control of services is centralized in the launchctl application.

On its own, launchctl can take commands from the command line, from standard in, or operate in interactive mode. With superuser privileges, launchctl can be used to make changes on a global scale. A set of launchctl commands can be made permanent when stored in /etc/launchd.conf. (A per-user ~/.launchd.conf file appears to have been considered, but is not supported in any existing version of macOS.[2])

launchctl communicates with launchd via a Mach-specific IPC mechanism.

A property list (plist) is a type of file that launchd uses for program configuration. When launchd scans a folder, or a job is submitted with launchctl, it reads a plist file that describes how the program is to be run.

A list of often used keys follows below. All keys are optional unless otherwise noted. For a full list, see Apple's manpage for launchd.plist.[3]