mach_init(8) [opendarwin man page]
MACH_INIT(8) BSD System Manager's Manual MACH_INIT(8) NAME
mach_init -- Mach service naming (bootstrap) daemon SYNOPSIS
mach_init [-D] [-d] [-F] [-r name-in-existing-server] DESCRIPTION
mach_init is a daemon that maintains various mappings between service names and the Mach ports that provide access to those services. Clients of mach_init can register and lookup services, create new mapping subsets, and associate services with declared servers. The mach_init daemon will also be responsible for launching (and/or re-launching) those service providing servers when attempts to use one or more of the associated services is detected. The options are as follows: -D When the -D option is specified, mach_init starts in normal (non-debug) mode. Logging is minimal (only security-related and process launch failures are logged). Core dumps are disabled for launched servers. This is the default. -d When the -d option is specified, mach_init starts in debug mode. Logging is extensive. Core dumps will be taken for any launched servers that crash. -F When the -F option is specified, mach_init forks during initialization so that it doesn't have to be put in the background manually by the caller. -r Using the -r option tells mach_init to register itself in a previously running copy of mach_init under the service name name-in-existing-server. This is most useful when debugging new instances of mach_init itself, but can also be used for robustness or to allow the subsequent mach_init processes to run as a non-root user. As mach_init is often used to launch servers, this could be more secure. However, mach_init will not allow a server declaration to specify a user id different than that of the requesting client (unless the client is running as root). So it shouldn't be required for a secure configuration. Access to mach_init is provided through the bootstrap series of RPC APIs over service ports published by mach_init itself. Each Mach task has an assigned bootstrap port retrieved via task_get_bootstrap_port(). These bootstrap port registrations are inherited across fork(). The service registrations are grouped into subsets, providing a level of security. Only processes with access to the subset's bootstrap port will be able to register/lookup Mach ports within that subset. Lookups from within a subset will search the subset first, then move on to its parent, and then its grand-parent, etc... until a string name match is found or the top of the bootstrap tree is reached. Subsets are sometimes associated with login sessions to protect session-specific ports from being exposed outside the session. The first instance of mach_init is responsible for launching the traditional BSD process control initialization daemon (/sbin/init). SAMPLE USAGE
mach_init -d -r com.company.bootstrap mach_init will start in debug mode, and register itself in an already running instance of mach_init under the service name com.company.boot- strap. NOTE
Sending a SIGHUP to a running mach_init will toggle debug mode. SEE ALSO
init(8) Mac OS X March 20, 2002 Mac OS X
Check Out this Related Man Page
launchctl(1) BSD General Commands Manual launchctl(1) NAME
launchctl -- Interfaces with launchd SYNOPSIS
launchctl [subcommand [arguments ...]] DESCRIPTION
launchctl interfaces with launchd to load, unload daemons/agents and generally control launchd. launchctl supports taking subcommands on the command line, interactively or even redirected from standard input. These commands can be stored in $HOME/.launchd.conf or /etc/launchd.conf to be read at the time launchd starts. SUBCOMMANDS
load [-wF] [-S sessiontype] [-D domain] 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 the user loading them. All system-wide daemons (LaunchDaemons) must be owned by root. Configuration files must not be group- or world-writable. 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 Overrides the Disabled key and sets it to false. In previous versions, this option would modify the configuration file. Now the state of the Disabled key is stored elsewhere on-disk. -F Force the loading of the plist. Ignore the Disabled key. -S sessiontype Some jobs only make sense in certain contexts. This flag instructs launchctl 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. Currently known session types include: Aqua, LoginWindow, Background, StandardIO and System. -D domain Look for plist(5) files ending in *.plist in the domain given. Valid domains include "system," "local," "network" and "all." When providing a session type, an additional domain is available for use called "user." For example, without a ses- sion type given, "-D system" would load from property list files from /System/Library/LaunchDaemons. With a session type passed, it would load from /System/Library/LaunchAgents. unload [-w] [-S sessiontype] [-D domain] paths ... Unload the specified configuration files or directories of configuration files. This will also stop the job if it is running. -w Overrides the Disabled key and sets it to true. In previous versions, this option would modify the configuration file. Now the state of the Disabled key is stored elsewhere on-disk. -S sessiontype Some jobs only make sense in certain contexts. This flag instructs launchctl 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. Currently known session types include: Aqua, LoginWindow, Background, StandardIO and System. -D domain Look for plist(5) files ending in *.plist in the domain given. Valid domains include "system," "local," "network" and "all." When providing a session type, an additional domain is available for use called "user." For example, without a ses- sion type given, "-D system" would load from property list files from /System/Library/LaunchDaemons. With a session type passed, it would load from /System/Library/LaunchAgents. submit -l label [-p executable] [-o path] [-e path] -- command [args] A simple way of submitting a program to run without a configuration file. This mechanism also tells launchd to keep the program alive in the event of failure. -l label What unique label to assign this job to launchd. -p program What program to really execute, regardless of what follows the -- in the submit sub-command. -o path Where to send the stdout of the program. -e path Where to send the stderr of the program. remove job_label Remove the job from launchd by label. start job_label Start the specified job by label. The expected use of this subcommand is for debugging and testing so that one can manually kick- start an on-demand server. stop job_label Stop the specified job by label. If a job is on-demand, launchd may immediately restart the job if launchd finds any criteria that is satisfied. Non-demand based jobs will always be restarted. Use of this subcommand is discouraged. Jobs should ideally idle timeout by themselves. list [-x] [label] 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 killed the job. Thus, "-15" would indicate that the job was terminated with SIGTERM. The third column is the job's label. Note that you may see some jobs in the list whose labels are in the style "0xdeadbeef.anonymous.program". These are jobs which are not managed by launchd, but, at one point, made a request to it. launchd claims no ownership and makes no guarantees regarding these jobs. They are stored purely for bookkeeping purposes. Similarly, you may see labels of the style "0xdeadbeef.mach_init.program". These are legacy jobs that run under mach_init emulation. This mechanism will be removed in future versions, and all remaining mach_init jobs should be converted over to launchd. If [label] is specified, prints information about the requested job. If [-x] is specified, the information for the specified job is output as an XML property list. setenv key value Set an environmental variable inside of launchd. unsetenv key Unset an environmental variable inside of launchd. getenv key Get an environmental variable inside of launchd. export Export all of the environmental variables of launchd for use in a shell eval statement. getrusage self | children Get the resource utilization statistics for launchd or the children of launchd. log [level loglevel] [only | mask loglevels...] Get and set the syslog(3) log level mask. The available log levels are: debug, info, notice, warning, error, critical, alert and emergency. limit [cpu | filesize | data | stack | core | rss | memlock | maxproc | maxfiles] [both [soft | hard]] With no arguments, this command prints all the resource limits of launchd as found via getrlimit(2). When a given resource is spec- ified, 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). shutdown Tell launchd to prepare for shutdown by removing all jobs. umask [newmask] Get or optionally set the umask(2) of launchd. bslist [PID | ..] [-j] This prints out Mach bootstrap services and their respective states. While the namespace appears flat, it is in fact hierarchical, thus allowing for certain services to be only available to a subset of processes. The three states a service can be in are active ("A"), inactive ("I") and on-demand ("D"). If [PID] is specified, print the Mach bootstrap services available to that PID. If [..] is specified, print the Mach bootstrap ser- vices available in the parent of the current bootstrap. Note that in Mac OS X v10.6, the per-user Mach bootstrap namespace is flat, so you will only see a different set of services in a per-user bootstrap if you are in an explicitly-created bootstrap subset. If [-j] is specified, each service name will be followed by the name of the job which registered it. bsexec PID command [args] This executes the given command in the same Mach bootstrap namespace hierachy as the given PID. bstree [-j] This prints a hierarchical view of the entire Mach bootstrap tree. If [-j] is specified, each service name will be followed by the name of the job which registered it. Requires root privileges. managerpid This prints the PID of the launchd which manages the current bootstrap. manageruid This prints the UID of the launchd which manages the current bootstrap. managername This prints the name of the launchd job manager which manages the current bootstrap. See LimitLoadToSessionType in launchd.plist(5) for more details. help Print out a quick usage statement. ENVIRONMENTAL VARIABLES
LAUNCHD_SOCKET This variable informs launchctl how to find the correct launchd to talk to. If it is missing, launchctl will use a built-in default. FILES
~/Library/LaunchAgents Per-user agents provided by the user. /Library/LaunchAgents Per-user agents provided by the administrator. /Library/LaunchDaemons System wide daemons provided by the administrator. /System/Library/LaunchAgents Mac OS X Per-user agents. /System/Library/LaunchDaemons Mac OS X System wide daemons. SEE ALSO
launchd.plist(5), launchd.conf(5), launchd(8) Darwin 1 May, 2009 Darwin