Launchd
From Wikipedia, the free encyclopedia
- The correct title of this article is launchd. The initial letter is shown capitalized due to technical restrictions.
launchd is a unified, open source service management framework for starting, stopping and managing daemons, programs and scripts. It was introduced with Mac OS X v10.4/Darwin v8.0, and is licensed under the Apache License. Dave Zarzycki is credited with designing and maintaining launchd.
The launchd daemon is essentially a replacement for init, rc, the init.d and rc.d scripts, SystemStarter (Mac OS X), inetd and xinetd, atd, crond and watchdogd. Apple has stated that it intends to eliminate all of the aforementioned services in favor of launchd. As of OS X v10.4 Apple has moved most of the processes handled by the previously mentioned daemons to launchd. By consolidating all the launch services into one program, launchd significantly shortens boot time on slow computers.
Contents |
[edit] launchd Components
There are two main programs in the launchd system: launchd and launchctl.
launchd manages the daemons at both a system and user level. Similar to xinetd, launchd can start daemons on demand. Similar to watchdogd, launchd can monitor daemons to make sure that they keep running. launchd also has replaced init as PID 1 on Mac OS X and as a result it is responsible for starting the system at boot time.
Configuration files define the parameters of services run by launchd. Stored in the LaunchAgents and LaunchDaemons subdirectories of the Library folders, the property list-based files have around thirty different keys that can be set.
launchctl is a command line application used to load and unload daemons, start and stop launchd controlled jobs, get system utilization statistics for launchd and its child processes, and set environment settings.
[edit] 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 10.4 system startup on a PowerPC Mac (on an Intel Mac, EFI replaces Open Firmware and boot.efi replaces BootX):
- Open Firmware activates, does its thing to the hardware, and then loads BootX.
- BootX loads the kernel, spins the pinwheel cursor, and loads any needed kernel extensions (kexts), and then the kernel loads launchd.
- launchd runs
/etc/rc, scans through/System/Library/LaunchDaemonsand/Library/LaunchDaemonsand acts on the plists as needed, and starts the login window.
In step 3, launchd scans through a few different directories for jobs to run. There are two different folders that are scanned. The LaunchDaemons folders contain items that will run as root, generally background processes. The LaunchAgents folders 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 folders 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 launchd scans through the job plists at boot time it reserves and listens 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 not. 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.
Consequently, Mac OS X 10.4 boots much faster than previous releases. The system only has to register the daemons that are to run, not actually launch them. 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 launch dependencies on 10.4. Using IPC will allow the daemons to talk amongst themselves to work it out, or you 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. The SystemStarter is an option that is still supported at this time, but it has been deprecated in Mac OS X 10.4; it may not be available in future OS X versions.
[edit] launchctl
One of the major complaints with the other facilities for service control is that they are strewn across the OS with no central way to manage them. launchctl is Apple's way of fixing this.
On its own, launchctl can take commands from the command line, from standard in, or operate in interactive mode. A set of commands can be made permanent when stored in ~/.launchd.conf or /etc/launchd.conf. With sudo, launchctl can be used to make changes on a global scale.
[edit] Property list
A property list (plist) is a type of file that Apple 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 oft-used keys follows below. For a full list, see Apple's manpage for launchd.plist.
| Key | Description | Required |
|---|---|---|
| Label | The name of the job | Yes |
| ProgramArguments | Strings to pass to the program when it is executed | Yes |
| UserName | The job will be run as the given user, who may not necessarily be the one who submitted it to launchd. | No |
| inetdCompatibility | Indicates that the daemon expects to be run as if it was launched by inetd | No |
| Program | The path to your executable. This key can save the ProgramArguments key for flags and arguments. | No |
| onDemand | A boolean flag that defines if a job runs continuously or not | No |
| RootDirectory | The job will be chrooted into another directory | No |
| ServiceIPC | Whether the daemon can speak IPC to launchd | No |
| WatchPaths | Allows launchd to start a job based on modifications at a file-system path | No |
| QueueDirectories | Similar to WatchPath, a queue will only watch an empty directory for new files | No |
| StartInterval | Used to schedule a job that runs on a repeating schedule | No |
| StartCalendarInterval | Job scheduling. The syntax is similar to cron. | No |
| HardResourceLimits | Controls restriction of the resources consumed by any job | No |
| LowPriorityIO | Tells the kernel that this task is of a low priority when doing file system I/O | No |
| Sockets | An array can be used to specify what socket the daemon will listen on for launch on demand | No |
[edit] Criticism
Some people feel that launchd makes too many decisions in the name of performance instead of correctness and flexibility. Some of the criticisms are:
- While it tremendously speeds the boot process on a simple stand-alone machine, it makes things difficult for more complex systems. For example, a boot failure would be very hard to fix as all services are started by a single script. System V arrangements group services in 4 levels, minimizing the number of services one has to look at for problems.
- By design, it removes System V flexibility as it is not possible to maintain order or selectively start services in the boot process.
This can be bad when, for example, a NetInfo or LDAP server is used for authentication, or when a user's home directory is hosted on a remote system, because LoginWindow will not be blocked until these essential services become available. However, if, in that example, the APIs LoginWindow calls to look up information in Directory Services were to block until Directory Services were to establish bindings to a NetInfo or LDAP server or to determine that no such server is available, and if its access to the user's home directory were to block until it is possible to mount it from the server, this would not be an issue; that is how it works in practice.
The idea is that if some piece of software depends on service x being available, it should block until service x is available, rather than having that dependency enforced by a configuration file. (Note that, in Unix-like systems not using launchd, any ordering of services often merely prevents a later service from starting until the program implementing a service on which it depends launching; it does not necessarily block the later service from starting until the program implementing the service on which it depends is ready to respond to requests for that service.
For example, if you start two daemons in sequence in an rc file, the second daemon might well request services from the first daemon before the first daemon has finished starting up.)
[edit] See also
[edit] External links
- Getting Started with launchd at developer.apple.com
- launchd's source code at Mac OS Forge
- launchd site at macosforge.org
- launchd in Depth: The basis for much of this article.
- All About launchd Items (and How To Make One Yourself): The creation of property lists for launchd
- Launchd Editor, a shareware editor for creating launchd service property lists
- Lingon, an Open Source editor for creating launchd service property lists
- launchd - FreeBSD-Wiki, launchd ported to FreeBSD
