supervisor
Generic Supervisor Behaviour
A behaviour module for implementing a supervisor, a process which
supervises other processes called child processes. A child
process can either be another supervisor or a worker process.
Worker processes are normally implemented using one of
the gen_event
, gen_fsm
, or gen_server
behaviours. A supervisor implemented using this module will have
a standard set of interface functions and include functionality
for tracing and error reporting. Supervisors are used to build an
hierarchical process structure called a supervision tree, a
nice way to structure a fault tolerant application. Refer to
OTP Design Principles for more information.
A supervisor assumes the definition of which child processes to supervise to be located in a callback module exporting a pre-defined set of functions.
Unless otherwise stated, all functions in this module will fail if the specified supervisor does not exist or if bad arguments are given.
Supervision Principles
The supervisor is responsible for starting, stopping and monitoring its child processes. The basic idea of a supervisor is that it should keep its child processes alive by restarting them when necessary.
The children of a supervisor is defined as a list of child specifications. When the supervisor is started, the child processes are started in order from left to right according to this list. When the supervisor terminates, it first terminates its child processes in reversed start order, from right to left.
A supervisor can have one of the following restart strategies:
-
one_for_one
- if one child process terminates and should be restarted, only that child process is affected. -
one_for_all
- if one child process terminates and should be restarted, all other child processes are terminated and then all child processes are restarted. -
rest_for_one
- if one child process terminates and should be restarted, the 'rest' of the child processes -- i.e. the child processes after the terminated child process in the start order -- are terminated. Then the terminated child process and all child processes after it are restarted. -
simple_one_for_one
- a simplifiedone_for_one
supervisor, where all child processes are dynamically added instances of the same process type, i.e. running the same code.The functions
delete_child/2
andrestart_child/2
are invalid forsimple_one_for_one
supervisors and will return{error,simple_one_for_one}
if the specified supervisor uses this restart strategy.The function
terminate_child/2
can be used for children undersimple_one_for_one
supervisors by giving the child'spid()
as the second argument. If instead the child specification identifier is used,terminate_child/2
will return{error,simple_one_for_one}
.
To prevent a supervisor from getting into an infinite loop of
child process terminations and restarts, a maximum restart frequency is defined using two integer values MaxR
and MaxT
. If more than MaxR
restarts occur within
MaxT
seconds, the supervisor terminates all child
processes and then itself.
This is the type definition of a child specification:
child_spec() = {Id,StartFunc,Restart,Shutdown,Type,Modules} Id = term() StartFunc = {M,F,A} M = F = atom() A = [term()] Restart = permanent | transient | temporary Shutdown = brutal_kill | int()>=0 | infinity Type = worker | supervisor Modules = [Module] | dynamic Module = atom()
-
Id
is a name that is used to identify the child specification internally by the supervisor. -
StartFunc
defines the function call used to start the child process. It should be a module-function-arguments tuple{M,F,A}
used asapply(M,F,A)
.
The start function must create and link to the child process, and should return
{ok,Child}
or{ok,Child,Info}
whereChild
is the pid of the child process andInfo
an arbitrary term which is ignored by the supervisor.
The start function can also return
ignore
if the child process for some reason cannot be started, in which case the child specification will be kept by the supervisor but the non-existing child process will be ignored.
If something goes wrong, the function may also return an error tuple
{error,Error}
.
Note that the
start_link
functions of the different behaviour modules fulfill the above requirements. -
Restart
defines when a terminated child process should be restarted. Apermanent
child process should always be restarted, atemporary
child process should never be restarted and atransient
child process should be restarted only if it terminates abnormally, i.e. with another exit reason thannormal
. -
Shutdown
defines how a child process should be terminated.brutal_kill
means the child process will be unconditionally terminated usingexit(Child,kill)
. An integer timeout value means that the supervisor will tell the child process to terminate by callingexit(Child,shutdown)
and then wait for an exit signal with reasonshutdown
back from the child process. If no exit signal is received within the specified number of milliseconds, the child process is unconditionally terminated usingexit(Child,kill)
.If the child process is another supervisor,
Shutdown
should be set toinfinity
to give the subtree ample time to shutdown.Important note on simple-one-for-one supervisors: The dynamically created child processes of a simple-one-for-one supervisor are not explicitly killed, regardless of shutdown strategy, but are expected to terminate when the supervisor does (that is, when an exit signal from the parent process is received).
Note that all child processes implemented using the standard OTP behavior modules automatically adhere to the shutdown protocol.
-
Type
specifies if the child process is a supervisor or a worker. -
Modules
is used by the release handler during code replacement to determine which processes are using a certain module. As a rule of thumbModules
should be a list with one element[Module]
, whereModule
is the callback module, if the child process is a supervisor, gen_server or gen_fsm. If the child process is an event manager (gen_event) with a dynamic set of callback modules,Modules
should bedynamic
. See OTP Design Principles for more information about release handling. -
Internally, the supervisor also keeps track of the pid
Child
of the child process, orundefined
if no pid exists.
Not a pid()
.
A
(the argument list) has the value
undefined
if Restart
is temporary
.
Functions
start_link/2
start_link/3
Creates a supervisor process as part of a supervision tree. The function will, among other things, ensure that the supervisor is linked to the calling process (its supervisor).
The created supervisor process calls
to
find out about restart strategy, maximum restart frequency
and child processes. To ensure a synchronized start-up
procedure, start_link/2,3
does not return until
has returned and all child processes
have been started.
If
the supervisor is registered
locally as Name
using register/2
. If
the supervisor is registered
globally as Name
using global:register_name/2
.
If no name is provided, the supervisor is not registered.
is the name of the callback module.
is an arbitrary term which is passed as
the argument to
.
If the supervisor and its child processes are successfully
created (i.e. if all child process start functions return
{ok,Child}
, {ok,Child,Info}
, or ignore
)
the function returns {ok,Pid}
, where Pid
is
the pid of the supervisor. If there already exists a process
with the specified
the function returns
{error,{already_started,Pid}}
, where Pid
is
the pid of that process.
If
returns ignore
, this function
returns ignore
as well and the supervisor terminates
with reason normal
.
If
fails or returns an incorrect value,
this function returns {error,Term}
where Term
is a term with information about the error, and the supervisor
terminates with reason Term
.
If any child process start function fails or returns an error
tuple or an erroneous value, the function returns
{error,shutdown}
and the supervisor terminates all
started child processes and then itself with reason
shutdown
.
start_child/2
Dynamically adds a child specification to the supervisor
which starts the corresponding child process.
- the pid,
Name
, if the supervisor is locally registered,{Name,Node}
, if the supervisor is locally registered at another node, or{global,Name}
, if the supervisor is globally registered.
should be a valid child specification
(unless the supervisor is a simple_one_for_one
supervisor, see below). The child process will be started by
using the start function as defined in the child
specification.
If the case of a simple_one_for_one
supervisor,
the child specification defined in Module:init/1
will
be used and
should instead be an arbitrary
list of terms
. The child process will then be
started by appending
to the existing start
function arguments, i.e. by calling
apply(M, F, A++
where {M,F,A}
is the start
function defined in the child specification.
If there already exists a child specification with
the specified
,
is discarded and
the function returns {error,already_present}
or
{error,{already_started,
, depending on if
the corresponding child process is running or not.
If the child process start function returns {ok,
or {ok,
, the child specification and pid is
added to the supervisor and the function returns the same
value.
If the child process start function returns ignore
,
the child specification is added to the supervisor, the pid
is set to undefined
and the function returns
{ok,undefined}
.
If the child process start function returns an error tuple or
an erroneous value, or if it fails, the child specification is
discarded and the function returns {error,Error}
where
Error
is a term containing information about the error
and child specification.
terminate_child/2
Tells the supervisor
to terminate the given
child.
If the supervisor is not simple_one_for_one
,
must be the child specification identifier. The
process, if there is one, is terminated but the child
specification is kept by the supervisor. The child process
may later be restarted by the supervisor. The child process
can also be restarted explicitly by calling
restart_child/2
. Use delete_child/2
to remove
the child specification.
If the supervisor is simple_one_for_one
,
must be the child process' pid()
. I the specified
process is alive, but is not a child of the given
supervisor, the function will return
{error,not_found}
. If the child specification
identifier is given instead instead of a pid()
, the
function will return {error,simple_one_for_one}
.
If successful, the function returns ok
. If there is
no child specification with the specified
, the
function returns {error,not_found}
.
See start_child/2
for a description of
.
delete_child/2
Tells the supervisor
to delete the child
specification identified by
. The corresponding child
process must not be running, use terminate_child/2
to
terminate it.
See start_child/2
for a description of
SupRef
.
If successful, the function returns ok
. If the child
specification identified by
exists but
the corresponding child process is running, the function
returns {error,running}
. If the child specification
identified by
does not exist, the function returns
{error,not_found}
.
restart_child/2
Tells the supervisor
to restart a child process
corresponding to the child specification identified by
. The child specification must exist and
the corresponding child process must not be running.
See start_child/2
for a description of
SupRef
.
If the child specification identified by
does not
exist, the function returns {error,not_found}
. If
the child specification exists but the corresponding process
is already running, the function returns
{error,running}
.
If the child process start function returns {ok,
or {ok,
, the pid is added to the supervisor
and the function returns the same value.
If the child process start function returns ignore
,
the pid remains set to undefined
and the function
returns {ok,undefined}
.
If the child process start function returns an error tuple or
an erroneous value, or if it fails, the function returns
{error,
where
is a term containing
information about the error.
which_children/1
Returns a newly created list with information about all child
specifications and child processes belonging to
the supervisor
.
Note that calling this function when supervising a large number of children under low memory conditions can cause an out of memory exception.
See start_child/2
for a description of
SupRef
.
The information given for each child specification/process is:
-
- as defined in the child specification orId undefined
in the case of asimple_one_for_one
supervisor. -
- the pid of the corresponding child process, orChild undefined
if there is no such process. -
- as defined in the child specification.Type -
- as defined in the child specification.Modules
count_children/1
Returns a property list (see proplists
) containing the
counts for each of the following elements of the supervisor's
child specifications and managed processes:
-
specs
- the total count of children, dead or alive. -
active
- the count of all actively running child processes managed by this supervisor. -
supervisors
- the count of all children marked as child_type = supervisor in the spec list, whether or not the child process is still alive. -
workers
- the count of all children marked as child_type = worker in the spec list, whether or not the child process is still alive.
check_childspecs/1
This function takes a list of child specification as argument
and returns ok
if all of them are syntactically
correct, or {error,
otherwise.
CALLBACK FUNCTIONS
The following functions should be exported from a
supervisor
callback module.
Functions
Module:init(Args) -> Result
Args = term()
Result = {ok,{{RestartStrategy,MaxR,MaxT},[ChildSpec]}} | ignore
RestartStrategy = strategy()
MaxR = MaxT = integer()>=0
ChildSpec = child_spec()
Whenever a supervisor is started using
supervisor:start_link/2,3
, this function is called by
the new process to find out about restart strategy, maximum
restart frequency and child specifications.
Args
is the Args
argument provided to the start
function.
RestartStrategy
is the restart strategy and
MaxR
and MaxT
defines the maximum restart
frequency of the supervisor. [ChildSpec]
is a list of
valid child specifications defining which child processes
the supervisor should start and monitor. See the discussion
about Supervision Principles above.
Note that when the restart strategy is
simple_one_for_one
, the list of child specifications
must be a list with one child specification only.
(The Id
is ignored). No child process is then started
during the initialization phase, but all children are assumed
to be started dynamically using
supervisor:start_child/2
.
The function may also return ignore
.