config - Configuration file.
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.
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.
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.
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.
app(5),
erts:erl(1), OTP Design Principles