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.

       Configuration  parameter  values  in  the  configuration  file  override the values in the
       application resource files (see app(5)). The values  in  the  configuration  file  can  be
       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 configurations.

       This means that  specifying  another  .config  file,  or  more  .config  files,  leads  to
       inconsistent  update  of  application  configurations.  There  is,  however,  a syntax for
       sys.config that allows pointing out other .config files:

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

         File = string():
           Name of another .config file. Extension .config can be omitted. It is  recommended  to
           use absolute paths. If a relative path is used, File is searched, first, relative from
           sys.config directory, then relative to the current working directory of the  emulator,
           for  backward compatibility. This allow to use a sys.config pointing out other .config
           files in a release or in a node started manually using -config ...  with  same  result
           whatever the current working directory.

       When traversing the contents of sys.config 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 overwritten.

       Example:

       sys.config:

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

       myconfig.config:

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

       This yields the following environment for myapp:

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

       The behavior if a file specified in  sys.config  does  not  exist,  or  is  erroneous,  is
       backwards  compatible.  Starting  the  runtime  system will fail. Installing a new release
       version will not fail, but an error message is returned and the erroneous file is ignored.

SEE ALSO

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