Supervisors are processes which monitor the behavior of workers. A

supervisor can restart a worker if something goes wrong.The supervisor is

responsible for starting, stopping and  monitoring its child processes.

Workers are processes which perform computations.

A supervisor can supervise  either workers or supervisors. Hereafter we will

use the term child to mean either a worker or a supervisor.

Supervision trees can be manipulated by using the functions exported

from the module supervisor

A typical supervision tree looks as follows:

The square boxes represent supervisors.

The circles represent workers.

The properties of a supervisor are defined by the supervisor flags. This is the

type definition for the supervisor flags:

sup_flags() = #{strategy => strategy(), intensity => non_neg_integer(), period => pos_integer()} These flags are option. Supervisors restart strategies strategy key are- 

• one_for_one - if one child process terminates and should be restarted, only that child process is affected. This is the default restart strategy.

• 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 simplified one_for_one supervisor, where all child processes are dynamically added instances of the same process type, i.e. running the same code.

To prevent a supervisor from getting into an infinite loop of child process

terminations and restarts, a maximum restart intensity is defined using two

integer values specified with the intensity and period keys in the above

map. Assuming the values MaxR for intensity and MaxT for period, then if

more than MaxR restarts occur within MaxT seconds, the supervisor will

terminate all child processes and then itself. The default value for intensity

is 1, and the default value for period is 5.

This is the type definition of a child specification:

child_spec() = #{id => child_id(), start => mfargs(), restart => restart(), shutdown => shutdown(), type => worker(), modules => modules()} 

id is used to identify the child specification internally by the supervisor.

The id key is mandatory.

Note that this identifier on occations has been called "name". As far as

possible, the terms "identifier" or "id" are now used but in order to keep

backwards compatibility, some occurences of "name" can still be found, for

example in error messages.

start defines the function call used to start the child process. It must be a

module-function-arguments tuple {M,F,A} used as apply(M,F,A).

The start function must create and link to the child process, and must

return {ok,Child} or {ok,Child,Info} where Child is the pid of the child

process and Info 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 (unless it is a temporary child) 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.

The start key is mandatory.

restart defines when a terminated child process shall be restarted. A

permanent child process will always be restarted, a temporary child

process will never be restarted (even when the supervisor's restart strategy

is rest_for_one or one_for_all and a sibling's death causes the temporary

process to be terminated) and a transient child process will be restarted

only if it terminates abnormally, i.e. with another exit reason than normal,

shutdown or {shutdown,Term}.

The restart key is optional. If it is not given, the default value permanent will

be used.

• shutdown defines how a child process shall be terminated. brutal_kill means the child process will be unconditionally terminated using exit(Child,kill). An integer timeout value means that the supervisor will tell the child process to terminate by calling exit(Child,shutdown) and then wait for an exit signal with reason shutdown back from the child process. If no exit signal is received within the specified number of milliseconds, the child process is unconditionally terminated using exit(Child,kill).
• If the child process is another supervisor, the shutdown time should be set to infinity to give the subtree ample time to shut down. It is also allowed to set it to infinity, if the child process is a worker.
• Note that all child processes implemented using the standard OTP behaviour modules automatically adhere to the shutdown protocol.
• The shutdown key is optional. If it is not given, the default value 5000 will be used if the child is of type worker; and infinity will be used if the child is of type supervisor.
• type specifies if the child process is a supervisor or a worker.
• The type key is optional. If it is not given, the default value worker will be used.
• modules is used by the release handler during code replacement to determine which processes are using a certain module. As a rule of thumb, if the child process is a supervisor, gen_server, or gen_fsm, this should be a list with one element [Module], where Module is the callback module. If the child process is an event manager (gen_event) with a dynamic set of callback modules, the value dynamic shall be used. See OTP Design Principles for more information about release handling.
• The modules key is optional. If it is not given, it defaults to [M], where M comes from the child's start {M,F,A}
• Internally, the supervisor also keeps track of the pid Child of the child process, or undefined if no pid exists.