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 will 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 erl(1)).

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

FILE SYNTAX

       The configuration file should be called Name.config where Name is an arbitrary name.

       The .config file contains one single Erlang term. The file has the following syntax:

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

         * Application = atom() is the name of the application.

         * Par = atom() is the name of a configuration parameter.

         * Val = term() is the 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 should 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,  or  additional,  .config  files  would  lead   to
       inconsistent  update of application configurations. Therefore, in Erlang 5.4/OTP R10B, the
       syntax of sys.config was extended to allow pointing out other .config files:

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

         * File = string() is the name of another .config file.  The  extension  .config  may  be
           omitted.  It  is  recommended  to  use absolute paths. A relative path is relative the
           current working directory of the emulator.

       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 will yield the following environment for myapp:

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

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

SEE ALSO

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