What is launchd.plist on macOSlaunchd.plist is the plist fil

launchd.plist is the plist file to configure daemon/agent on macOS.

This article details the parameters which can be given to a plist that can be loaded into launchd with launchctl

Note:

Plist file are expected to have a .plist extension name
The expected full name of plist files is <Label>.plist.

Typical Parameters or `<key>`s

Label <string>

uniquely identifies the job to launchd.

[Disabled] <boolen>

whether the job should be loaded by default.

[UserName] <string>

specifies the user to run the job as. This key is only applicable for services that are loaded into the privileged system domain.

[GroupName] <string>

specifies the group to run the job as. This key is only applicable for services that are loaded into the privileged system domain. If UserName is set and GroupName is not, then the group will be set to the primary group of the user.

Program <string>

This key maps to the first argument of execv(3) and indicates the absolute path to the executable for the job. If this key is missing, then the first element of the array of strings provided to the ProgramArguments will be used instead. This key is required in the absence of the ProgramArguments key.

ProgramArguments <array of strings>

This key maps to the second argument of execvp(3) and specifies the argument vector to be passed to the job when a process is spawned. This key is required in the absence of the Program key. IMPORTANT: Many people are confused by this key. Please read execvp(3) very carefully!. Note: The Program key must be an absolute path. In the absence of the Program key, the first element of the ProgramArguments array may be either an absolute path, or a relative path which is resolved using _PATH_STDPATH.

[KeepAlive] <boolean or dictionary of stuff>

This optional key is used to control whether your job is to be kept continuously running or to let demand and conditions control the invocation. The default is false and therefore only demand will start the job. The value may be set to true to unconditionally keep the job alive. Alternatively, a dictionary of conditions may be specified to selectively control whether launchd keeps a job alive or not. If multiple keys are provided, launchd ORs them, thus providing maximum flexibility to the job to refine the logic and stall if necessary. If launchd finds no reason to restart the job, it falls back on demand based invocation. Jobs that exit quickly and frequently when configured to be kept alive will be throttled to conserve system resources.

The typical conditions:

PathState <dictionary of booleans>
Each key in this dictionary is a file-system path. If the value of the key is true, then the job will be kept alive as long as the path exists. If false, the job will be kept alive in the inverse condition. The intent of this feature is that two or more jobs may create semaphores in the file- system namespace. The following example keeps the job alive as long as the file /path/to/file exists.
```
<key>KeepAlive</key>
<dict>
    <key>PathState</key>
    <dict>
    <key>/path/to/file</key>
    <true/>
    </dict>
</dict>
```
IMPORTANT: Filesystem monitoring mechanisms are inherently race- prone and lossy. This option should be avoided in favor of demand- based alternatives using IPC.
SuccessfulExit <boolean>
If true, the job will be restarted as long as the program exits and with an exit status of zero. If false, the job will be restarted in the inverse condition. This key implies that "RunAtLoad" is set to true, since the job needs to run at least once before an exit status can be determined.
Crashed <boolean>
If true, the the job will be restarted as long as it exited due to a signal which is typically associated with a crash (SIGILL, SIGSEGV, etc.). If false, the job will be restarted in the inverse condition.

[WorkingDirectory] <string>

This optional key is used to specify a directory to chdir(2) to before running the job.

[EnvironmentVariables] <dictionary of strings>

This optional key is used to specify additional environmental variables to be set before running the job. Each key in the dictionary is the name of an environment variable, with the corresponding value being a string representing the desired value. NOTE: Values other than strings will be ignored.

[Umask] <integer or string>

This optional key specifies what value should be passed to umask(2) before running the job. If the value specified is an integer, it must be a decimal representation of the desired umask, as property lists do not support encoding integers in octal. If a string is given, the string will be converted into an integer as per the rules described in strtoul(3), and an octal value may be specified by prefixing the string with a '0'. If a string that does not cleanly convert to an integer is specified, the behavior will be to set a umask(2) according to the strtoul(3) parsing rules.

[ThrottleInterval] <integer>

This key lets one override the default throttling policy imposed on jobs by launchd. The value is in seconds, and by default, jobs will not be spawned more than once every 10 seconds. The principle behind this is that jobs should linger around just in case they are needed again in the near future. This not only reduces the latency of responses, but it encourages developers to amortize the cost of program invocation.

[InitGroups] <boolean>

This optional key specifies whether initgroups(3) to initialize the group list for the job. The default is true. This key will be ignored if the UserName key is not set. Note that for agents, the UserName key is ignored.

[QueueDirectories] <array of strings>

This optional key keeps the job alive as long as the directory or directories specified are not empty.

[StartOnMount] <boolean>

This optional key causes the job to be started every time a filesystem is mounted.

[StartInterval] <integer>

This optional key causes the job to be started every N seconds. If the system is asleep during the time of the next scheduled interval firing, that interval will be missed due to shortcomings in kqueue(3). If the job is running during an interval firing, that interval firing will likewise be missed.

[StartCalendarInterval] <dictionary of integers or array of dictionaries of integers >

This optional key causes the job to be started every calendar interval as specified. Missing arguments are considered to be wildcard. The semantics are similar to crontab(5) in how firing dates are specified. Multiple dictionaries may be specified in an array to schedule multiple calendar intervals.

Unlike cron which skips job invocations when the computer is asleep, launchd will start the job the next time the computer wakes up. If multiple intervals transpire before the computer is woken, those events will be coalesced into one event upon wake from sleep

Note that StartInterval and StartCalendarInterval are not aware of each other. They are evaluated completely independently by the system.

Minute <integer>
The minute (0-59) on which this job will be run.

Hour <integer>
The hour (0-23) on which this job will be run.

Day <integer>
The day of the month (1-31) on which this job will be run.

Weekday <integer>
The weekday on which this job will be run (0 and 7 are Sunday). If
both Day and Weekday are specificed, then the job will be started
if either one matches the current date.

Month <integer>
The month (1-12) on which this job will be run.

[StandardInPath] <string>

This optional key specifies that the given path should be mapped to the job's stdin(4), and that the contents of that file will be readable from the job's stdin(4). If the file does not exist, no data will be delivered to the process' stdin(4).

[StandardOutPath] <string>

This optional key specifies that the given path should be mapped to the job's stdout(4), and that any writes to the job's stdout(4) will go to the given file. If the file does not exist, it will be created with writable permissions and ownership reflecting the user and/or group specified as the UserName and/or GroupName, respectively (if set) and permissions reflecting the umask(2) specified by the Umask key, if set.

[StandardErrorPath] <string>

This optional key specifies that the given path should be mapped to the job's [stderr(4)][12], and that any writes to the job's stderr(4) will go to the given file. Note that this file is opened as readable and writable as mandated by the POSIX specification for unclear reasons. If the file does not exist, it will be created with ownership reflecting the user and/or group specified as the UserName and/or GroupName, respectively (if set) and permissions reflecting the umask(2) specified by the Umask key, if set.

[Debug] <boolean>

This optional key specifies that launchd should adjust its log mask temporarily to LOG_DEBUG while dealing with this job.

[WaitForDebugger] <boolean>\

This optional key specifies that launchd should launch the job in a sus- pended state so that a debugger can be attached to the process as early as possible (at the first instruction).

[Nice] <integer>

This optional key specifies what nice(3) value should be applied to the daemon.

[ProcessType] <string>

This optional key describes, at a high level, the intended purpose of the job. The system will apply resource limits based on what kind of job it is. If left unspecified, the system will apply light resource limits to the job, throttling its CPU usage and I/O bandwidth. This classification is preferable to using the HardResourceLimits, SoftResourceLimits and Nice keys. The following are valid values:

Background
Background jobs are generally processes that do work that was not
directly requested by the user. The resource limits applied to
Background jobs are intended to prevent them from disrupting the
user experience.

Standard
Standard jobs are equivalent to no ProcessType being set.

Adaptive
Adaptive jobs move between the Background and Interactive classifi-
cations based on activity over XPC connections. See
xpc_transaction_begin(3) for details.

Interactive
Interactive jobs run with the same resource limitations as apps,
that is to say, none. Interactive jobs are critical to maintaining
a responsive user experience, and this key should only be used if
an app's ability to be responsive depends on it, and cannot be made
Adaptive.

[AbandonProcessGroup] <boolean>

When a job dies, launchd kills any remaining processes with the same process group ID as the job. Setting this key to true disables that behavior.

[LowPriorityIO] <boolean>

This optional key specifies whether the kernel should consider this daemon to be low priority when doing filesystem I/O.

[LowPriorityBackgroundIO] <boolean>

This optional key specifies whether the kernel should consider this dae- mon to be low priority when doing filesystem I/O when the process is throttled with the Darwin-background classification.

[LaunchOnlyOnce] <boolean>

This optional key specifies whether the job can only be run once and only once. In other words, if the job cannot be safely respawned without a full machine reboot, then set this key to be true.

CAVEATS

Daemons and agents managed by launchd are subject to macOS user privacy protections. Specifying privacy sensitive files and folders in a launchd plist may not have the desired effect, and may prevent the job from running.

Examples

For sample configuration property lists, look at the files in /System/Library/LaunchDaemons/. These files are used to configure many daemons that run on OS X.

What is launchd.plist on macOS

Typical Parameters or <key>s