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 argument.

       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