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