Elixir 1.9 provides runtime config. When set it up by providing a config/releases.exs, it will copy this file to _build/prod/rel/APP/releases/VSN/release.exs and when start the release via bin/App start_iex, it will first start beam, then restart beam within the same os process, then starting again.
I’m not quite sure what’s the reason behind restarting beam? Here’s my guess:
When starting beam, kernel application will start application_controller process, who will load all env’s in sys.config, which is generated via the config/config.exs(this is the compile time config). All the application’s env are stored in an ets table called ac_tab.
After all application started, some code will load the configs in config/releases.exs, and update ac_tab with runtime config
Then a restart beam command is issued, maybe via :init.restart(), all the application is shutdown
Then all the application is starting again, but this time with runtime config inserted in ac_tab, so the application will have access to the runtime config when they starts
Is that why beam needs to restarts when runtime config is provided?
The reason for restart is to allow configuring the kernel and stdlib applications, in particular, various distribution flags. Otherwise, since as you said, kernel is started before config is loaded, you wouldn’t be able to change those configurations.
Isn’t there a solution where you wouldn’t need to restart the beam? Using it as a server proves no problem, you just have to wait a few seconds, however in cases for example when you would want to embed it in an android application this will create a big delay. I remember a sample config used before elixir releases having something like: config_key: "$ENV_VARIABLE"
Not sure if this works anymore.
There’s a :reboot_system_after_config setting for mix release, which allows for loading config without the reboot (cannot configure kernel and stdlib as mentioned). It seems to be buggy on 1.10 with releases.exs, but it should work on 1.11 with runtime.exs.
