Prepare with:
./autogen.sh && ./configure --with-rebar=./rebar3 && make
Or use this if you installed Elixir:
./autogen.sh && ./configure --with-rebar=mix && make
Start without installing (it recompiles when necessary):
make relive
It stores config, database and logs in _build/relive/
There's available the well-known script:
_build/relive/ejabberdctl
Please note this fails immediately:
r3:do(compile).
This crashes a few seconds later:
rebar3:run(["compile"]).
Workaround that works correctly:
ejabberd_admin:update().
For detached connection we free socket, so let's make code account for this
(and we really need it for printing debug informations).
This makes sure we call ejabberd_sm:close_session
Previously we stored only message/subject change notifications, but if user
request also change notificaitons for affiliation/config/subscribers then
i don't see reason why we shouldn't store it as well.
Let the size of the cache used for 'special' groups (such as @all@ or
@online@) depend on the number of virtual hosts, as the cache will
contain seperate entries per domain.
Thanks to Ingo Jrgensmann for reporting the issue.
Don't forget to normalize the JID handed over from ejabberd_sm on
presence-unavailable. Without normalization, mod_shared_roster might
fail to look up the storage backend for the given host name, for
example.
Fixes#3752.
Rebar 2 expands {{erts-vsn}} to "erts-$vsn", Rebar 3 expands it to just
"$vsn". Make sure `make rel` doesn't end up with a "$vsn" directory
next to "erts-$vsn" (which happened when using Rebar 3), and make sure
that ejabberdctl expects both "erl" and "epmd" to be installed below
"erts-$vsn" (which it didn't when using Rebar 3).
That script serves a similar purpose to ejabberdctl to start ejabberd,
but we can't guarantee it is completely equivalent to ejabberdctl.
The prod profile must provide only the well-known script.
The test profile provides the Relx script so we can experiment with it.
