NAME

       config - Configuration file.

DESCRIPTION

       A  configuration file contains values for configuration parameters for the applications in
       the system. The erl command-line argument -config Name tells the system to use data in the
       system configuration file Name.config.

       The  erl  command-line  argument  -configfd  works  the same way as the -config option but
       specifies a file descriptor to read configuration data from instead of a file.

       The configuration data from configuration files and file descriptors are read in the  same
       order  as  they  are  given  on  the  command line. For example, erl -config a -configfd 3
       -config b -configfd 4 would cause the system to read configuration data in  the  following
       order  a.config,  file  descriptor  3, b.config, and file descriptor 4. If a configuration
       parameter is specified more than once in the given files and file  descriptors,  the  last
       one overrides the previous ones.

       Configuration  parameter  values  in  a configuration file or file descriptor override the
       values in the application resource files (see app(5)). The  values  in  the  configuration
       file are always overridden by command-line flags (see erts:erl(1)).

       The value of a configuration parameter is retrieved by calling application:get_env/1,2.

FILE SYNTAX

       The configuration file is to be called Name.config, where Name is any name.

       File .config contains a single Erlang term and has the following syntax:

       [{Application1, [{Par11, Val11}, ...]},
        ...
        {ApplicationN, [{ParN1, ValN1}, ...]}].

         Application = atom():
           Application name.

         Par = atom():
           Name of a configuration parameter.

         Val = term():
           Value of a configuration parameter.

SYS.CONFIG

       When starting Erlang in embedded mode, it is assumed that exactly one system configuration
       file is used, named sys.config. This file is to be located  in  $ROOT/releases/Vsn,  where
       $ROOT is the Erlang/OTP root installation directory and Vsn is the release version.

       Release handling relies on this assumption. When installing a new release version, the new
       sys.config is read and used to update the application's configurations.

       This means that specifying another .config file,  or  more  .config  files,  leads  to  an
       inconsistent  update  of application configurations. There is, however, a way to point out
       other config files from a sys.config. How to do this is described in the next section.

INCLUDING FILES FROM SYS.CONFIG AND -CONFIGFD CONFIGURATIONS

       There is a way to include other configuration files from a  sys.config  file  and  from  a
       configuration  that  comes  from  a  file  descriptor  that  has been pointed out with the
       -configfd command-line arguemnt.

       The syntax for including files can be described by the Erlang type language like this:

       [{Application, [{Par, Val}]} | IncludeFile].

         IncludeFile = string():
           Name of a .config file. The extension .config can be omitted. It is recommended to use
           absolute  paths.  If a relative path is used in a sys.config, IncludeFile is searched,
           first, relative to the sys.config directory, then  relative  to  the  current  working
           directory  of  the  emulator. If a relative path is used in a -configfd configuration,
           IncludeFile is searched, first, relative to the dictionary containing the boot  script
           (see  also  the  -boot  command-line  argument) for the emulator, then relative to the
           current working directory of the emulator. This makes it possible  to  use  sys.config
           for  pointing out other .config files in a release or in a node started manually using
           -config or -configfd with the same result whatever the current working directory is.

       When traversing the contents of a sys.config or a -configfd configuration and  a  filename
       is  encountered,  its  contents  are  read  and  merged  with  the  result so far. When an
       application configuration tuple {Application, Env} is found, it is merged with the  result
       so  far.  Merging  means  that  new parameters are added and existing parameter values are
       overwritten.

       Example:

       sys.config:

       ["/home/user/myconfig1"
        {myapp,[{par1,val1},{par2,val2}]},
        "/home/user/myconfig2"].

       myconfig1.config:

       [{myapp,[{par0,val0},{par1,val0},{par2,val0}]}].

       myconfig2.config:

       [{myapp,[{par2,val3},{par3,val4}]}].

       This yields the following environment for myapp:

       [{par0,val0},{par1,val1},{par2,val3},{par3,val4}]

       The run-time system will  abort  before  staring  up  if  an  include  file  specified  in
       sys.config  or  a  -configfd  configuration  does  not  exist,  or  is erroneous. However,
       installing a new release version will not fail if there  is  an  error  while  loading  an
       include file, but an error message is returned and the erroneous file is ignored.

SEE ALSO

       app(5), erts:erl(1), OTP Design Principles