That way HiPE compilation can be performed during package installation
and will not waste time during every startup.
rabbit_hipe is refactored to support both modes of compilation - during
every server startup or separately with caching in the filesystem.
We previously did the same change in #273 (PR: #275),
but the file in which it was done was removed in 231e90cacf.
Note that #592 recommends using `-r` unconditionally but that option
is not recognised by sed which ships with OS X.
After further investigation, the problem was not an inconsistency
between hostname(1) and Erlang, but a `/etc/rabbitmq/rabbitmq-env.conf`
in Travis CI's host having `NODENAME=rabbit@localhost`. See #402.
The real problem is therefore the testsuite which should ignore
`/etc/rabbitmq/rabbitmq-env.conf`.
The Windows side of the change is kept because it fixes a real issue.
References #402.
So if RABBITMQ_PLUGINS_DIR is explicitely set in the environment, do not
run rabbitmqctl. Likewise for RABBITMQ_ENABLED_PLUGINS_FILE.
This prevents rabbitmq-plugins from taking configuration from a running
unrelated node, when it is started from `make run-broker`. The make
command will still fail later but for the correct reason: there is
already a node conflicting with the one we want to start.
Without this, `make run-broker` would abort with the following error:
Error: {cannot_write_enabled_plugins_file,
"./sbin/../etc/rabbitmq/enabled_plugins",enoent}
... which doesn't make any sense.
The user shouldn't override the init script's RABBITMQ_PID_FILE value,
otherwise the init script erroneously reports failures to start or stop
the service.
Now, rabbitmq-env logs a warning if RABBITMQ_PID_FILE is already defined
in the environment (ie. by the init script) and in rabbitmq-env.conf.
Fixes#127.
This fixes at least one problem with $RABBITMQ_PID_FILE which, by
default, is set to:
RABBITMQ_PID_FILE=${RABBITMQ_MNESIA_DIR}.pid
In this case, if $RABBITMQ_MNESIA_DIR ends with a trailing slash, the
PID file is a hidden file placed in the Mnesia directory. This prevents
auto-clustering from working and this is tricky to understand why.
Fixes#118.
If this is the case, log a warning to stderr.
Here is an example with the plugins expansion directory:
WARNING: RABBITMQ_PLUGINS_EXPAND_DIR is located inside RABBITMQ_MNESIA_DIR
=> Auto-clustering will not work ('cluster_nodes' in rabbitmq.config)
And with the log directory:
WARNING: RABBITMQ_LOG_BASE is equal to RABBITMQ_MNESIA_DIR
RABBITMQ_LOGS is located inside RABBITMQ_MNESIA_DIR
RABBITMQ_SASL_LOGS is located inside RABBITMQ_MNESIA_DIR
=> Auto-clustering will not work ('cluster_nodes' in rabbitmq.config)
Fixes#120.
Before this change, they were written to /var/log/rabbitmq, no matter
the value of RABBITMQ_LOG_BASE.
In rabbitmq-env, allow the caller to set RABBITMQ_SCRIPTS_DIR to the
directory where rabbitmq-env and rabbitmq-default are located.
In both Fedora and Debian rabbitmq-server.init and
rabbitmq-script-wrapper, load rabbitmq-env and use RABBITMQ_LOG_BASE.
The default value is /var/log/rabbitmq, so the default behaviour remains
the same.
In Debian's rabbitmq-script-wrapper version, use RABBITMQ_LOG_BASE
instead of the hard-coded /var/log/rabbitmq.
Fixes#88.
Michael Klishin
Karl Nilsson
Diana Corbacho
Alexey Lebedeff
Daniil Fedotov
Chris Bandy
Jean-Sébastien Pédron
Jean-Sébastien Pédron
Michael Klishin
Daniil Fedotov
Simon MacMullen
Michael Klishin