Currently, Elixir expressions are evaluated on an EMQX node using the
'eval' command, which works for both Erlang and Elixir expressions.
This commit adds the new command 'eval-ex' exclusively for evaluating
Elixir expressions on Elixir nodes, similar to 'eval-erl' for Erlang.
Prior to this change, when EMQX daemon mode failed to start
it's not quite easy for users to understand what went wrong.
All the know is the node did not start in time
and then instructed to boot the node in 'console' mode wishing
for some logs.
However, the node might actuay be running, causing 'console' mode
to fail with a different reason.
With this change, after a filure of daemon mode boot,
we issue a diagnosis.
1. if node can not be found from ps -ef, instruct the user
to find information in erlang.log.N
2. if the node is found running, but not responding to pings
instruct the user to check if the node name is
resolvable and reachable
3. if the node is responding to pings but emqx app is not
running, then it's likely a bug. so the user is advised
to report a github issue.
If more than one node is boot from the same root directory
try to find the node by node name set in EMQX_NODE_NAME
or EMQX_NODE__NAME environment variable
https://emqx.atlassian.net/browse/EMQX-6978
[Related EIP](c4864eeccb/active/0022-forward-check-install-upgrade-script.md)
Currently, when performing a hot upgrade, the scripts that are run are
those from the currently installed EMQX version. It has a validation
that prevents upgrade between different minor versions. If we want to
allow an upgrade from, say, 5.0.x to 5.1.y, then the scripts in
already released packages will deny such operation. Also, if an
upgrade installation script contains a bug in the current, it will
never be able to execute properly without manual patching.
By attempting to execute the scripts from the target version, we may
add fixes and new validations to new EMQX versions and have them
executed by older versions.
Before this change, if a license in `emqx.conf` was of type
`key`/`file` and then changed to the opposite type, such change would
be saved to `{cluster,local}-overrides.conf`. When the node restarts
after that, the configs are merged naively and becomes invalid, as it
contains both the `key` and `file` keys, and crashes.
The CLI emqx_ctl fails:
```
./bin/emqx_ctl status
Node not initialized?
Generated config file vm.*.args is not found for command 'ctl'
in config dir: /Users/liuxy/code/emqx50/_build/emqx/rel/emqx/-emqx_data_dir /Users/liuxy/code/emqx50/_build/emqx/rel/emqx/data --/configs
In case the file has been deleted while the node is running,
set environment variable 'EMQX_NODE__NAME' to continue
```
The main slow-down is the overheads of booting up beam with the
'start_clean' boot file (which loads all modules).
Prior to this change, beam is started multiple times in order to
resolve configuration values.
After this change:
* For boot commands such as 'start', 'console' and
'foreground', it starts beam twice:
- 1st is to check platform compatibility
- 2nd is to resolve all configs required for boot in a batch
* For non-boot commands, such as 'ctl' and 'ping', it does not
require to start beam for config resolution at all
Adds a check to `bin/emqx` to see if the OTP version being used has
support for `mnesia_hook`, which is required by Mria for using the
RLOG backend. If OTP is not compatible and the user tries to use
RLOG, a warning is printed during startup and the configuration falls
back to using the Mnesia backend.
some of the find_ functions are generated from the old rebar template
which will never be used since we:
1. always release erts
2. always generate sys.config
3. always generate vm.args
for remsh prefixed nodes, ekka pick a random port to listen on
instead of following the conventional port mapping rule:
ekka listens on 4370 for emqx or emqx0 and 4371 for emqx1 and so on
With the previous arguments, a fresh hidden node with the same name as
the expected running one was being started and commands were being run
there. This caused commands like `ekka_cluster:info()` to report
seemingly weird results.
OTP release handler only works with .tar.gz
as a result, we had to unpack .zip and re-pack .tar.gz
just to make OTP happy.
Now since we will be building .tar.gz packages
there is no need for this re-pack step anymore
Zaiming (Stone) Shi