.TH config 5 "kernel 9.2.3" "Ericsson AB" "Files"
.SH NAME
config \- Configuration file.
.SH DESCRIPTION
.LP
A \fIconfiguration file\fR\& contains values for configuration parameters for the applications in the system\&. The \fIerl\fR\& command-line argument \fI-config Name\fR\& tells the system to use data in the system configuration file \fIName\&.config\fR\&\&.
.LP
The erl command-line argument \fI-configfd\fR\& works the same way as the \fI-config\fR\& option but specifies a file descriptor to read configuration data from instead of a file\&.
.LP
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, \fIerl -config a -configfd 3 -config b -configfd 4\fR\& would cause the system to read configuration data in the following order \fIa\&.config\fR\&, file descriptor \fI3\fR\&, \fIb\&.config\fR\&, and file descriptor \fI4\fR\&\&. If a configuration parameter is specified more than once in the given files and file descriptors, the last one overrides the previous ones\&.
.LP
Configuration parameter values in a configuration file or file descriptor override the values in the application resource files (see \fIapp(5)\fR\&)\&. The values in the configuration file are always overridden by command-line flags (see \fIerts:erl(1)\fR\&)\&.
.LP
The value of a configuration parameter is retrieved by calling \fIapplication:get_env/1,2\fR\&\&.
.SH "FILE SYNTAX"

.LP
The configuration file is to be called \fIName\&.config\fR\&, where \fIName\fR\& is any name\&.
.LP
File \fI\&.config\fR\& contains a single Erlang term and has the following syntax:
.LP
.nf

[{Application1, [{Par11, Val11}, ...]},
 ...
 {ApplicationN, [{ParN1, ValN1}, ...]}].
.fi
.RS 2
.TP 2
.B
\fIApplication = atom()\fR\&:
Application name\&.
.TP 2
.B
\fIPar = atom()\fR\&:
Name of a configuration parameter\&.
.TP 2
.B
\fIVal = term()\fR\&:
Value of a configuration parameter\&.
.RE
.SH "SYS.CONFIG"

.LP
When starting Erlang in embedded mode, it is assumed that exactly one system configuration file is used, named \fIsys\&.config\fR\&\&. This file is to be located in \fI$ROOT/releases/Vsn\fR\&, where \fI$ROOT\fR\& is the Erlang/OTP root installation directory and \fIVsn\fR\& is the release version\&.
.LP
Release handling relies on this assumption\&. When installing a new release version, the new \fIsys\&.config\fR\& is read and used to update the application\&'s configurations\&.
.LP
This means that specifying another \fI\&.config\fR\& file, or more \fI\&.config\fR\& files, leads to an inconsistent update of application configurations\&. There is, however, a way to point out other config files from a \fIsys\&.config\fR\&\&. How to do this is described in the next section\&.
.SH "INCLUDING FILES FROM SYS.CONFIG AND -CONFIGFD CONFIGURATIONS"

.LP
There is a way to include other configuration files from a \fIsys\&.config\fR\& file and from a configuration that comes from a file descriptor that has been pointed out with the \fI-configfd\fR\& command-line argument\&.
.LP
The syntax for including files can be described by the Erlang type language like this:
.LP
.nf

[{Application, [{Par, Val}]} | IncludeFile].
.fi
.RS 2
.TP 2
.B
\fIIncludeFile = string()\fR\&:
Name of a \fI\&.config\fR\& file\&. The extension \fI\&.config\fR\& can be omitted\&. It is recommended to use absolute paths\&. If a relative path is used in a \fIsys\&.config\fR\&, \fIIncludeFile\fR\& is searched, first, relative to the \fIsys\&.config\fR\& directory, then relative to the current working directory of the emulator\&. If a relative path is used in a \fI-configfd\fR\& configuration, \fIIncludeFile\fR\& is searched, first, relative to the dictionary containing the boot script (see also the \fI-boot\fR\& command-line argument) for the emulator, then relative to the current working directory of the emulator\&. This makes it possible to use \fIsys\&.config\fR\& for pointing out other \fI\&.config\fR\& files in a release or in a node started manually using \fI-config\fR\& or \fI-configfd\fR\& with the same result whatever the current working directory is\&. 
.RE
.LP
When traversing the contents of a \fIsys\&.config\fR\& or a \fI-configfd\fR\& configuration and a filename is encountered, its contents are read and merged with the result so far\&. When an application configuration tuple \fI{Application, Env}\fR\& is found, it is merged with the result so far\&. Merging means that new parameters are added and existing parameter values are overwritten\&.
.LP
\fIExample:\fR\&
.LP
.nf

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}]}].
.fi
.LP
This yields the following environment for \fImyapp\fR\&:
.LP
.nf

[{par0,val0},{par1,val1},{par2,val3},{par3,val4}]
.fi
.LP
The run-time system will abort before staring up if an include file specified in \fIsys\&.config\fR\& or a \fI-configfd\fR\& 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\&.
.SH "SEE ALSO"

.LP
\fIapp(5)\fR\&, \fIerts:erl(1)\fR\&, OTP Design Principles