launchd

from Wikipedia, the free encyclopedia

launchd is a uniform framework for starting, managing and terminating daemons , programs and shell scripts in the operating system context. It was introduced with Mac OS X Tiger (10.4) and Darwin v8.0 . In terms of usage, it is under the Apache license . Dave Zarzycki , then employed by the US company Apple , developed launchd.

The launchd daemon should take over the following functions:

With Mac OS X Tiger (10.4), Apple has transferred most of the tasks to launchd . By standardizing the start of services on a single process, launchd accelerates the necessary start time, especially on slow computers.

Components of launchd

The core components of the launchd system are:

  • launchd
  • launchctl

launchd manages the “daemons” on both the user and system level. Similar to xinetd , launchd can start “daemons” on request. Like watchdogd , launchd can monitor “daemons” and ensure that they are always running. In addition, launchd has replaced init as PID 1 on Mac OS X and is therefore responsible for the system start (boot process).

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

launchctl is a command line program, which has the task of loading and unloading "daemons". It can also be used to start and stop services controlled by launchd, to obtain statistics about the system utilization for launchd and its child processes, and finally to set environment variables.

launchd

launchd has two tasks:

  1. to start (boot) the system,
  2. load and monitor the services (i.e. ensure that they are still running and have not terminated unplanned).

The following section shows a simplified representation of the system to boot from Mac OS X 10.4 on a PowerPC -Mac (on a Intel -Mac replaces EFI the Open Firmware , and boot.efireplaces BootX ):

  1. Open firmware is activated, initialized and checked the hardware and then loads BootX.
  2. BootX loads the operating system kernel, shows the start animation (the rotating wind turbine) and loads all necessary kernel extensions (kexts). Then the kernel loads launchd.
  3. launchd starts /etc/rc, searches the directories /System/Library/LaunchDaemonsand /Library/LaunchDaemons, reacts according to the settings in the plist files and starts the login window.

In step 3, launchd searches some directories for services that need to be running. There are two directories for this: The LaunchDaemons directory contains commands that are executed as root (i.e. with system administrator rights); these are usually background processes. The directories called LaunchAgents contain certain commands, so-called agent applications , which are executed with user rights. These can be scripts or other foreground commands (i.e. visible ones), which can even have a user interface. These directories are all in the Mac OS X Library folders.

Launchd is very different from SystemStarter in that it actually doesn't necessarily load all of the "daemons" at system startup. The basic idea of ​​launchd is, as is also the case with xinetd, to only load the “daemons” when they are needed. While launchd searches the plist files with the commands when the system is started, it reserves all the (IP) ports requested there and listens to them. H. waits for requests on these ports. If the "OnDemand" key is defined in the plist file, the "daemon" is not yet started at this point in time. Instead, launchd “listens” to this port and only starts the “daemon” when it is needed and terminates it when it is no longer needed. After a “daemon” has been loaded, it is monitored by launchd. launchd ensures that it runs whenever it is needed. In this respect lauchd works like watchdogd and, like watchdogd, demands that the process not attempt to "fork" or "daemonize" itself. As soon as a process is moved to the background, launchd loses control of it and tries to restart it.

As a result of this concept, Mac OS X 10.4 starts up much faster than its predecessor. The system only needs to register the "daemons" and not start immediately. In fact, the graphical progress bar during the startup process of the Mac is just a "placebo" program (called WaitingForLoginWindow), which shows nothing other than the passage of a certain period of time.

The most difficult aspect to deal with when starting the system via launchd is the dependencies between the services. The previous procedure via "SystemStarter" offered a very simple concept of defining dependencies, using the keywords "Uses", "Requires" and "Provides" in the plist file of an autostart object. However, there are two main strategies for resolving dependencies in MacOS 10.4. The interprocess communication enables the "daemons" to communicate with one another and negotiate dependencies, or one observes files or directory paths for changes. Using IPC is much more adept and sophisticated than the SystemStarter concept keywords, and it also requires more program development work, but it can result in cleaner and faster system starts. The SystemStarter is an option that is still available and supported in Mac OS X Tiger (10.4).

launchctl

One of the most important complaints about the implementation of other service administrations is that they are scattered across the system and there is no central administration tool for them. Apple uses launchctl to solve this problem.

When used on its own, launchctl accepts commands from the command line, standard input , or works interactively. A sequence of commands can be saved permanently using the file ~/.launchd.confor /etc/launchd.conf. In conjunction with sudo can launchctl be used to make changes to a global impact.

Property list

A property list (plist) is a file extension used by Apple to store program settings. Then when launchd searches a directory or submits a task to launchd, it reads the plist file that describes how to start the program.

The following table shows a list of frequently used keywords. For more information see Apple's "man page".

keyword description needed
Label The name of the task Yes
ProgramArguments Character strings as parameters to the program Yes
UserName The task will be started under the specified user name. It doesn't necessarily have to be the one who passed it to launchd . No
inetdCompatibility Indicates that the daemon is expecting to run as if it were started by inetd . No
Program The path to the executable file (program or shell script). This key can also contain the arguments, so that the ProgramArguments key value is no longer required. No
onDemand A switch ( boolean ) which determines whether a task should be started regardless of whether it is required. No
RootDirectory The task runs under a virtual file environment (via chroot ). No
ServiceIPC Indicates whether the daemon can communicate with launchd via IPC . No
WatchPaths Allows launchd to start a task from changes in a directory. No
QueueDirectories Similar to WatchPath, wait for new files to be created in an empty directory. No
StartInterval Needed to run a task regularly, similar to cron . No
StartCalendarInterval Starting tasks regularly. The syntax is similar to that of cron . No
HardResourceLimits Controls the restriction of certain resources that are provided by tasks. No
LowPriorityIO Tells the operating system kernel to give this task a lower priority while it waits for file operations. No
Sockets A list can be used to determine which "socket" the daemon should listen on. Used when a service should not be started until it is needed. No

criticism

Some people criticize launchd for being designed too much with startup speed in mind and not designed with correctness and flexibility in mind. In particular, these are:

  • While on the one hand the start-up process is immensely accelerated on a simple, independent system, on the other hand the situation on more complex systems becomes more complicated. For example, errors at system start-up are very difficult to locate and correct because all services are started by a single script. System V, on the other hand, separates the services into four "levels" and thus minimizes the number of services that need to be investigated in the event of problems.
  • Conceptually, launchd loses the flexibility of System V because it is not possible to set a startup sequence or selectively start services during the boot process.

This can lead to problems if e.g. B. a NetInfo or LDAP server is used for authentication or if the private user directory (home directory) is on a network server. Because the login window is not blocked until these services are active and available. On the other hand, if in the example mentioned the APIs used by the login window to determine information in the Directory Services block until the "Directory Services" have established the connection to the NetInfo or LDAP server or determine that no such server is available, and if access to the user directory is blocked until it can be mounted by the server, then that's no problem.

The idea is that if a program can only run when service x is available, it blocks until service x is actually available; the dependency is therefore determined implicitly in the software itself instead of through configuration files. (Note that in Unix- like systems that do not use launchd, setting the startup order only prevents later (i.e. dependent) services from starting before those services that depend on the former are started. However, this concept does not necessarily block the later (dependent) service long enough until the required service is initialized and ready for use.)

For example, if you start two “daemons” one after the other through a configuration file ( rc file ), it could happen that the second service needs functions of the first before it has finished its start process.

Web links

Unix "man pages" from Apple

Individual evidence

  1. AUTHORS file within Launchd package credits Dave Zarzycki
  2. WaitingForLoginWindow
  3. launchd.plist