launchd

Launchd is a unified framework for starting, managing, and stopping daemons, programs and shell scripts. It was introduced with Mac OS X v10.4/Darwin v8.0 and it is licensed under the Apache license. The employees at Apple Dave Zarzycki developed and currently maintains launchd.

The launchd daemon should incorporate the following functions:

• Init
• Rc
• Init.d
• Rc.d scripts
• Starter system
• Inetd
• xinetd
• Atd
• Crond
• Watchdogd

With OS X version 10.4 " Tiger", Apple has transferred most of the tasks to launchd. By standardizing the service - start on a single process accelerates launchd the necessary start- time, especially on slow computers significantly.

• 3.1 Unix " man pages " of Apple

Components of launchd

The core components of the launchd system are:

• Launchd
• Launchctl

Launchd manages the " Daemons" on both user - and system-level. Similar to xinetd launchd can start on demand " daemon ". How watchdogd can also launchd " Daemons" monitor and ensure that they are always running. Furthermore, launchd replaced init as PID 1 on Mac OS X and is thus responsible for the startup ( boot ).

The parameters of the services that can be started by launchd, are defined in configuration files. These files are located in the directories LaunchAgents and LaunchDaemons directory "Library" and are based on property list ( plist ), have approximately thirty editable key values.

Launchctl is a command line program, which has the task of loading and unloading of " daemons ". Furthermore, it can be used to start and stop launchd controlled services, to determine statistics on system utilization for launchd and its child processes, and finally how to set environment variables.

Launchd

Launchd has two tasks:

The following section shows a simplified representation of the system to boot from MacOS 10.4 on a PowerPC Mac ( on an Intel Mac EFI replaces the Open Firmware, and boot.efi replaced BootX ):

In step 3, launchd scans some directories for services that must be performed. There are two sets of directories: Directory LaunchDaemons contains commands that are executed as root (ie with root privileges ), usually these are background processes. The directories named LaunchAgents contain certain commands, so-called agent applications which are executed with user privileges. This can be scripts or other foreground commands ( ie visible ), which may even have a user interface. These directories are all located in the library folders from Mac OS X.

Launchd is very different from starter system, namely to the effect that it is actually not necessarily all " daemons " loads at startup. The basic idea is to launchd, as well as similar in xinetd to load the " daemons " only when they are needed. While launchd plist files by looking at system startup with the command, it allocates all those requested ( IP ) ports and listens to them, ie waits for requests on these ports. If in the plist file the key " OnDemand " is defined, the " daemon " is not started at this time. Instead, "listens " launchd on this port and starts the " daemon " only when it is needed, and ended it when it is no longer needed. After a " daemon " has been loaded, it is monitored by launchd. launchd thereby ensures that it runs whenever it is needed. In this regard, works lauchd as watchdogd and provides as watchdogd the request to the process that he does not try to execute independently a "fork" or " daemonize ". Once a process is moved to the background, launchd will lose control of it and tried to restart it.

As a result of this concept Mac OS X 10.4 starts much faster than its predecessors. The system only needs the " daemon " to register and to start immediately. In fact, the graphical progress bar when starting the Mac only a " placebo " program ( called WaitingForLoginWindow ), which otherwise shows as the expiry of a specified period of time.

The most difficult aspect to be managed at system startup via launchd are the dependencies of the services themselves. The current procedure in "System Starter" offered a very simple concept of the definition of a dependency, by the keywords "Uses ", " Requires " and " Provides " in the plist file of a startup object. In contrast, there are two main strategies to resolve dependencies in MacOS 10.4. The inter-process communication allows the " daemons ", to communicate and negotiate dependencies, or you observed files or directory paths with respect to changes. The use of IPC is much smarter and more sophisticated than the keywords of the starter system concept, and this also requires more work in program development, but it can lead to cleaner and faster system startup. The starter system is an option that is still available in 10.4 and is supported.

Launchctl

One of the main objections to the implementation of other services, administrations is that they are scattered all over the system and there is no central administration tool for it. Apple used launchctl to solve this problem.

If this is used on its own, accepted launchctl commands from the command line, from standard input, or is interactive. A sequence of commands can be saved permanently by using the file ~ /. Launchd.conf or / etc / launchd.conf. In conjunction with sudo launchctl can be used to make changes with global impact.

Property list

A property list ( plist ) is a file extension that is used by Apple to store program settings. If then launchd a directory searches or a task is sent to launchd, it reads the plist file that describes how the program has to be started.

The now following table shows a list of frequently used keywords. For more information, see Apple's " man page " ( launchd plist ).

Criticism

Some people criticize the fact that launchd has been developed too much in terms of startup speed and too little with the aim of accuracy and flexibility. These are in particular:

• While on the one hand the starting process is accelerated immensely on a simple, stand-alone system, the relationships are complicated to more complex systems on the other. For example, errors at startup are very difficult to localize and correct, as all services are run from a single script. System V, however, separating the services into four " levels ", thus minimizing the number of services that need to examine it in case of problems.
• Conceptually, launchd will lose the flexibility of System V, since it is not possible to define a startup sequence, or selectively to start services during the boot process.

This can lead to problems if, for example, a NetInfo or LDAP server is used for authentication, or if the private user directory (home directory) is located on a network server. Because the login window is not blocked until these services are active and available. On the other hand, the following applies: If in the above example the APIs used by the login window to discover information in the Directory Services block until the " Directory Services " have the connection to the NetInfo or LDAP servers manufactured or determine that no such server is available, and if the access is blocked to the user directory before it can be hung from the server, then that is no problem.

The idea is that a program, provided that it can run only if x service is available, blocked until x service is actually available. That the dependence is implicitly defined in the software itself rather than by configuration files. ( Note that in Unix -like systems that do not use launchd, a definition of the starting order only prevents later (ie dependent ) services are started before those services are started, on which depends the former. However, blocked this concept is not necessarily the later (dependent) service long enough for the service you need is initialized and ready for use.

If you sequentially through a configuration file (rc file) starts for example, two " daemon ", it could happen that the second service functions of the former needed before it has completed its startup process. )