launchctl(1) | General Commands Manual | launchctl(1) |
launchctl
—
Interfaces with launchd
launchctl |
subcommand [arguments ...] |
launchctl
interfaces with
launchd
to manage and inspect daemons, agents and
XPC services.
launchctl
allows for detailed examination
of launchd
's data structures. The fundamental
structures are domains, services, and endpoints. A domain manages the
execution policy for a collection of services. A service may be thought of
as a virtual process that is always available to be spawned in response to
demand. Each service has a collection of endpoints, and sending a message to
one of those endpoints will cause the service to launch on demand. Domains
advertise these endpoints in a shared namespace and may be thought of as
synonymous with Mach bootstrap subsets.
Many subcommands in launchctl
take a
specifier which indicates the target domain or service for the subcommand.
This specifier may take one of the following forms:
print
subcommand will display the ASID of that login domain. User-login domains
do not exist on iOS.login
specifier. Rather than
specifying a user-login domain by its ASID, this specifier targets the
domain based on which user it is associated with and is generally more
convenient.
Note: GUI domains and user domains share many resources. For the purposes of the Mach bootstrap name lookups, they are "flat", so they share the same set of registered names. But they still have discrete sets of services. So when printing the user domain's contents, you may see many Mach bootstrap name registrations from services that exist in the GUI domain for that user, but you will not see the services themselves in that list.
For instance, when referring to a service with the identifier
com.apple.example
loaded into the GUI domain of a
user with UID 501, domain-target
is
gui/501/
, service-name
is
com.apple.example
, and
service-target
is
gui/501/com.apple.example
.
If no paths or service target are specified, these commands can either bootstrap or remove a domain specified as a domain target. Some domains will implicitly bootstrap pre-defined paths as part of their creation.
-kp
]
service-targetlaunchd
to run the specified service
immediately, regardless of its configured launch conditions.
-ksx
]
service-target-k
-s
-x
launchd
maintainer.IMPORTANT: These arguments replace the service's default argument vector; they are not merged in any way. The first argument following -- is given as the initial (zeroth) element of the service's argument vector. As with the ProgramArguments launchd.plist(5) key, you should read carefully and understand the execve(2) man page.
launchd
launched the service. Note that services
may run for many reasons; this subcommand will only show the most
proximate reason. So if a service was run due to a timer firing, this
subcommand will print that reason, irrespective of whether there were
messages waiting on the service's various endpoints. This subcommand is
only intended for debugging and profiling use and its output should not be
relied upon in production scenarios.IMPORTANT: This output is NOT API in any sense at all. Do NOT rely on the structure or information emitted for ANY reason. It may change from release to release without warning.
launchd
service
cache.launchd
) and audit session context. This
subcommand is intended for diagnostic purposes only, and its output should
not be relied upon in production scenarios. This command requires root
privileges.launchd
. This subcommand requires root
privileges.launchd
to fork(2) itself
for examination by a profiling tool and prints the PID of this new
instance to stdout. You are responsible for killing this snapshot when it
is no longer needed.
Many profiling tools cannot safely examine
launchd
because they depend on the functionality
it provides. This subcommand creates an effective snapshot of
launchd
that can be examined independently. Note
that on Darwin platforms, fork(2) is implemented such
that only the thread which called fork(2) is
replicated into the new child process, so this subcommand is not useful
for examining any thread other than the main event loop.
This subcommand takes an optional invocation of a tool to be
used on the launchd
snapshot. Where you would
normally give the PID of the process to be examined in the tool's
invocation, instead specify the argument "@PID", and
launchctl
will substitute that argument with the
PID of the launchd snapshot in its subsequent execution of the tool. If
used in this form, launchctl
will automatically
kill the snapshot instance when the examination tool exits.
This subcommand may only be used against a DEVELOPMENT
launchd
.
Supported configuration parameters are:
NOTE: This facility cannot be used to set general environment variables for all services within the domain. It is intentionally scoped to the PATH environment variable and nothing else for security reasons.
launchd
to begin tearing down userspace.
With no argument given or with the system argument
given, launchd
will make the
reboot(2) system call when userspace has been completely
torn down. With the halt argument given,
launchd
will make the reboot(2)
system call when userspace has been completely torn down and pass the
RB_HALT flag, halting the system and not initiating
a reboot.
With the userspace argument given,
launchd
will re-exec itself when userspace has
been torn down and bring userspace back up. This is useful for rebooting
the system quickly under conditions where kernel data structures or
hardware do not need to be re-initialized.
With the logout argument given, launchd will tear down the caller's GUI login session in a manner similar to a logout initiated from the Apple menu. The key difference is that a logout initiated through this subcommand will be much faster since it will not give apps a chance to display modal dialogs to block logout indefinitely; therefore there is data corruption risk to using this option. Only use it when you know you have no unsaved data in your running apps.
With the apps argument given, launchd will terminate all apps running in the caller's GUI login session that did not come from a launchd.plist(5) on-disk. Apps like Finder, Dock and SystemUIServer will be unaffected. Apps are terminated in the same manner as the logout argument, and all the same caveats apply.
launchctl
will attempt to guess which error domain the code given belongs to. The
caller may optionally specify which domain (either
posix, mach, or
bootstrap) to interpret the given code as an error
from that subsystem.launchd
variant currently active on the
system. Possible variants include RELEASE, DEVELOPMENT and DEBUG.launchd
version string.Legacy subcommands select the target domain based on whether they are executed as root or not. When executed as root, they target the system domain.
-wF
] [-S
sessiontype] [-D
searchpath] paths ...Load the specified configuration files or directories of
configuration files. Jobs that are not on-demand will be started as soon
as possible. All specified jobs will be loaded before any of them are
allowed to start. Note that per-user configuration files (LaunchAgents)
must be owned by root (if they are located in
/Library/LaunchAgents
) or the user loading them
(if they are located in
$HOME/Library/LaunchAgents
). All system-wide
daemons (LaunchDaemons) must be owned by root. Configuration files must
disallow group and world writes. These restrictions are in place for
security reasons, as allowing writability to a launchd configuration
file allows one to specify which executable will be launched.
Note that allowing non-root write access to the
/System/Library/LaunchDaemons
directory WILL
render your system unbootable.
-w
launchd
.-F
-S
sessiontypelaunchctl
to look for jobs in a different
location when using the -D flag, and allows
launchctl
to restrict which jobs are loaded
into which session types. Sessions are only relevant for per-user
launchd
contexts. Relevant sessions are Aqua
(the default), Background and LoginWindow. Background agents may be
loaded independently of a GUI login. Aqua agents are loaded only when
a user has logged in at the GUI. LoginWindow agents are loaded when
the LoginWindow UI is displaying and currently run as root.-D
searchpath/System/Library/LaunchDaemons
.
With a session type passed, it would load from
/System/Library/LaunchAgents
. Note that
launchctl
no longer respects the network
search path.
In a previous version of launchd, these search paths were called "domains", hence -D. The word "domain" is now used for a totally different concept.
NOTE: Due to bugs in the previous implementation and long-standing client expectations around those bugs, the load and unload subcommands will only return a non-zero exit code due to improper usage. Otherwise, zero is always returned.
-l
label [-p
executable] [-o
stdout-path] [-e
stderr-path] -- command
[arg0] [arg1]
[...]With no arguments, list all of the jobs loaded into
launchd
in three columns. The first column
displays the PID of the job if it is running. The second column displays
the last exit status of the job. If the number in this column is
negative, it represents the negative of the signal which stopped the
job. Thus, "-15" would indicate that the job was terminated
with SIGTERM. The third column is the job's label. If
[label] is specified, prints information about the
requested job.
-x
launchd
in the caller's context.launchd
in the caller's
context.launchd
would set for all processes launched into
the caller's context.launchd
for use in a shell eval statement.launchd
or the children of
launchd
. This subcommand is not implemented.launchd
as found via
getrlimit(2). When a given resource is specified, it
prints the limits for that resource. With a third argument, it sets both
the hard and soft limits to that value. With four arguments, the third and
forth argument represent the soft and hard limits respectively. See
setrlimit(2).launchd
to prepare for shutdown by removing
all jobs. This subcommand is not implemented.launchd
. This subcommand is not implemented.launchd
processes each managing their own Mach
bootstrap subsets. In the current implementation, all bootstraps are
managed by one process, so this subcommand will always print
"1".The output produced by the "legacy" subcommands (chiefly list) should match their output on previous OS X releases. However, the output of newer subcommands does not conform to any particular format and is not guaranteed to remain stable across releases. These commands are intended for use by human developers and system administrators, not for automation by programs or scripts. Their output does not constitute an API and no promises of forward compatibility are offered to programs that attempt to parse it.
launchctl
no longer has an interactive
mode, nor does it accept commands from stdin. The
/etc/launchd.conf
file is no longer consulted for
subcommands to run during early boot time; this functionality was removed
for security considerations. While it was documented that
$HOME/.launchd.conf
would be consulted prior to
setting up a user's session, this functionality was never implemented.
launchd no longer uses Unix domain sockets for communication, so
the LAUNCHD_SOCKET
environment variable is no longer
relevant and is not set.
launchd
no longer loads configuration
files from the network
launchctl
will exit with status 0 if the
subcommand succeeded. Otherwise, it will exit with an error code that can be
given to the error subcommand to be decoded into
human-readable form.
1 October, 2014 | Darwin |