2014-06-09 20:53:57 +08:00
|
|
|
#!/bin/sh -e
|
2020-07-10 21:31:17 +08:00
|
|
|
## This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
## License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
## file, You can obtain one at https://mozilla.org/MPL/2.0/.
|
2009-07-22 22:48:50 +08:00
|
|
|
##
|
2024-02-06 00:53:36 +08:00
|
|
|
## Copyright (c) 2007-2025 Broadcom. All Rights Reserved. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. All rights reserved.
|
2009-07-22 22:48:50 +08:00
|
|
|
##
|
|
|
|
|
2015-04-08 17:52:50 +08:00
|
|
|
if [ "$RABBITMQ_ENV_LOADED" = 1 ]; then
|
|
|
|
return 0;
|
|
|
|
fi
|
|
|
|
|
2015-04-03 22:27:04 +08:00
|
|
|
if [ -z "$RABBITMQ_SCRIPTS_DIR" ]; then
|
|
|
|
# We set +e here since since our test for "readlink -f" below needs to
|
|
|
|
# be able to fail.
|
|
|
|
set +e
|
|
|
|
# Determine where this script is really located (if this script is
|
|
|
|
# invoked from another script, this is the location of the caller)
|
|
|
|
SCRIPT_PATH="$0"
|
|
|
|
while [ -h "$SCRIPT_PATH" ] ; do
|
|
|
|
# Determine if readlink -f is supported at all. TODO clean this up.
|
|
|
|
FULL_PATH=`readlink -f $SCRIPT_PATH 2>/dev/null`
|
|
|
|
if [ "$?" != "0" ]; then
|
|
|
|
REL_PATH=`readlink $SCRIPT_PATH`
|
|
|
|
if expr "$REL_PATH" : '/.*' > /dev/null; then
|
|
|
|
SCRIPT_PATH="$REL_PATH"
|
|
|
|
else
|
|
|
|
SCRIPT_PATH="`dirname "$SCRIPT_PATH"`/$REL_PATH"
|
|
|
|
fi
|
|
|
|
else
|
|
|
|
SCRIPT_PATH=$FULL_PATH
|
|
|
|
fi
|
|
|
|
done
|
|
|
|
set -e
|
|
|
|
|
|
|
|
RABBITMQ_SCRIPTS_DIR=`dirname $SCRIPT_PATH`
|
|
|
|
fi
|
|
|
|
|
2018-09-06 22:49:19 +08:00
|
|
|
_rmq_env_now()
|
|
|
|
{
|
|
|
|
date '+%Y-%m-%d %H:%M:%S'
|
|
|
|
}
|
|
|
|
|
|
|
|
_rmq_env_print()
|
|
|
|
{
|
|
|
|
_rmq_env_tmp="$1"
|
|
|
|
_rmq_env_tmp_len="${#_rmq_env_tmp}"
|
|
|
|
shift
|
|
|
|
printf '%s %s %s\n' "$(_rmq_env_now)" "$_rmq_env_tmp" "$1" 1>&2
|
|
|
|
shift
|
|
|
|
_rmq_env_print_line=''
|
|
|
|
_rmq_env_indent="$((_rmq_env_tmp_len + 21))"
|
|
|
|
for _rmq_env_print_line in "$@"
|
|
|
|
do
|
|
|
|
printf "%${_rmq_env_indent}s%s\n" ' ' "$_rmq_env_print_line" 1>&2
|
|
|
|
done
|
|
|
|
unset _rmq_env_print_line
|
|
|
|
unset _rmq_env_indent
|
|
|
|
unset _rmq_env_tmp_len
|
|
|
|
unset _rmq_env_tmp
|
|
|
|
}
|
|
|
|
|
|
|
|
_rmq_env_perr()
|
|
|
|
{
|
|
|
|
_rmq_env_print '[error]' "$@"
|
|
|
|
}
|
|
|
|
|
|
|
|
_rmq_env_pwarn()
|
|
|
|
{
|
|
|
|
_rmq_env_print '[warning]' "$@"
|
|
|
|
}
|
|
|
|
|
2015-10-30 19:33:26 +08:00
|
|
|
rmq_realpath() {
|
|
|
|
local path=$1
|
|
|
|
|
|
|
|
if [ -d "$path" ]; then
|
|
|
|
cd "$path" && pwd
|
|
|
|
elif [ -f "$path" ]; then
|
|
|
|
cd "$(dirname "$path")" && echo $(pwd)/$(basename "$path")
|
|
|
|
else
|
|
|
|
echo "$path"
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
RABBITMQ_HOME="$(rmq_realpath "${RABBITMQ_SCRIPTS_DIR}/..")"
|
2016-10-27 21:49:02 +08:00
|
|
|
ESCRIPT_DIR="${RABBITMQ_HOME}/escript"
|
2014-10-17 21:40:39 +08:00
|
|
|
|
2012-02-28 18:56:15 +08:00
|
|
|
## Set defaults
|
2015-04-03 22:27:04 +08:00
|
|
|
. ${RABBITMQ_SCRIPTS_DIR}/rabbitmq-defaults
|
2012-02-28 18:56:15 +08:00
|
|
|
|
2018-09-06 22:49:19 +08:00
|
|
|
# We save the current value of $RABBITMQ_PID_FILE in case it was set by
|
|
|
|
# an init script. If $CONF_ENV_FILE overrides it again, we must ignore
|
|
|
|
# it and warn the user.
|
|
|
|
saved_RABBITMQ_PID_FILE="$RABBITMQ_PID_FILE"
|
|
|
|
|
2017-08-23 00:52:24 +08:00
|
|
|
## Get configuration variables from the configure environment file
|
2022-08-31 06:31:43 +08:00
|
|
|
[ "x" = "x$RABBITMQ_CONF_ENV_FILE" ] && RABBITMQ_CONF_ENV_FILE="$CONF_ENV_FILE"
|
|
|
|
if [ -f "$RABBITMQ_CONF_ENV_FILE" ]; then
|
2020-04-06 19:00:08 +08:00
|
|
|
CONF_ENV_FILE_PHASE=rabbitmq-env
|
2022-08-31 06:31:43 +08:00
|
|
|
. "$RABBITMQ_CONF_ENV_FILE" || true
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Bump ETS table limit to 50000
|
|
|
|
if [ -z "$ERL_MAX_ETS_TABLES" ]; then
|
|
|
|
export ERL_MAX_ETS_TABLES=50000
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Default is defined here:
|
|
|
|
# https://github.com/erlang/otp/blob/master/erts/emulator/beam/erl_port.h
|
|
|
|
if [ -z "$ERL_MAX_PORTS" ]; then
|
|
|
|
export ERL_MAX_PORTS=65536
|
Move most of shell scripts to Erlang code
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
2019-05-15 22:27:51 +08:00
|
|
|
fi
|
2017-08-23 00:52:24 +08:00
|
|
|
|
2018-10-12 04:30:49 +08:00
|
|
|
[ -n "$ERL_EPMD_PORT" ] && export ERL_EPMD_PORT
|
|
|
|
[ -n "$ERL_EPMD_ADDRESS" ] && export ERL_EPMD_ADDRESS
|
|
|
|
|
2016-07-14 19:35:03 +08:00
|
|
|
DEFAULT_SCHEDULER_BIND_TYPE="db"
|
2018-02-26 20:05:20 +08:00
|
|
|
[ -n "$SCHEDULER_BIND_TYPE" ] || SCHEDULER_BIND_TYPE="$DEFAULT_SCHEDULER_BIND_TYPE"
|
|
|
|
[ -n "$RABBITMQ_SCHEDULER_BIND_TYPE" ] || RABBITMQ_SCHEDULER_BIND_TYPE="$SCHEDULER_BIND_TYPE"
|
2016-06-30 20:20:35 +08:00
|
|
|
|
2018-08-03 03:08:59 +08:00
|
|
|
DEFAULT_DISTRIBUTION_BUFFER_SIZE=128000
|
2018-02-26 20:05:20 +08:00
|
|
|
[ -n "$DISTRIBUTION_BUFFER_SIZE" ] || DISTRIBUTION_BUFFER_SIZE="$DEFAULT_DISTRIBUTION_BUFFER_SIZE"
|
|
|
|
[ -n "$RABBITMQ_DISTRIBUTION_BUFFER_SIZE" ] || RABBITMQ_DISTRIBUTION_BUFFER_SIZE="$DISTRIBUTION_BUFFER_SIZE"
|
2016-09-12 17:48:37 +08:00
|
|
|
|
2018-08-03 03:08:59 +08:00
|
|
|
DEFAULT_MAX_NUMBER_OF_PROCESSES=1048576
|
2018-02-26 20:05:20 +08:00
|
|
|
[ -n "$MAX_NUMBER_OF_PROCESSES" ] || MAX_NUMBER_OF_PROCESSES="$DEFAULT_MAX_NUMBER_OF_PROCESSES"
|
|
|
|
[ -n "$RABBITMQ_MAX_NUMBER_OF_PROCESSES" ] || RABBITMQ_MAX_NUMBER_OF_PROCESSES="$MAX_NUMBER_OF_PROCESSES"
|
2018-02-24 01:53:33 +08:00
|
|
|
|
2018-08-03 04:10:23 +08:00
|
|
|
DEFAULT_MAX_NUMBER_OF_ATOMS=5000000
|
2018-02-26 20:05:20 +08:00
|
|
|
[ -n "$MAX_NUMBER_OF_ATOMS" ] || MAX_NUMBER_OF_ATOMS="$DEFAULT_MAX_NUMBER_OF_ATOMS"
|
|
|
|
[ -n "$RABBITMQ_MAX_NUMBER_OF_ATOMS" ] || RABBITMQ_MAX_NUMBER_OF_ATOMS="$MAX_NUMBER_OF_ATOMS"
|
2016-09-12 17:48:37 +08:00
|
|
|
|
2021-02-10 19:35:12 +08:00
|
|
|
DEFAULT_SCHEDULER_BUSY_WAIT_THRESHOLD=none
|
|
|
|
[ -n "$SCHEDULER_BUSY_WAIT_THRESHOLD" ] || SCHEDULER_BUSY_WAIT_THRESHOLD="$DEFAULT_SCHEDULER_BUSY_WAIT_THRESHOLD"
|
|
|
|
[ -n "$RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD" ] || RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD="$SCHEDULER_BUSY_WAIT_THRESHOLD"
|
|
|
|
|
2018-01-30 02:56:30 +08:00
|
|
|
## Common server defaults
|
2022-10-08 07:04:43 +08:00
|
|
|
SERVER_ERL_ARGS="+pc unicode +P $RABBITMQ_MAX_NUMBER_OF_PROCESSES +t $RABBITMQ_MAX_NUMBER_OF_ATOMS +stbt $RABBITMQ_SCHEDULER_BIND_TYPE +zdbbl $RABBITMQ_DISTRIBUTION_BUFFER_SIZE +sbwt $RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD +sbwtdcpu $RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD +sbwtdio $RABBITMQ_SCHEDULER_BUSY_WAIT_THRESHOLD"
|
2012-01-04 23:57:19 +08:00
|
|
|
|
2014-07-03 19:08:05 +08:00
|
|
|
##--- Set environment vars RABBITMQ_<var_name> to defaults if not set
|
|
|
|
|
2020-06-25 21:20:23 +08:00
|
|
|
[ "x" = "x$RABBITMQ_CTL_ERL_ARGS" ] && RABBITMQ_CTL_ERL_ARGS="$CTL_ERL_ARGS"
|
|
|
|
[ "x" = "x$RABBITMQ_CTL_DIST_PORT_MIN" ] && RABBITMQ_CTL_DIST_PORT_MIN="$CTL_DIST_PORT_MIN"
|
|
|
|
[ "x" = "x$RABBITMQ_CTL_DIST_PORT_MAX" ] && RABBITMQ_CTL_DIST_PORT_MAX="$CTL_DIST_PORT_MAX"
|
|
|
|
[ "x" = "x$RABBITMQ_CTL_DIST_PORT_MIN" ] && RABBITMQ_CTL_DIST_PORT_MIN='35672'
|
|
|
|
[ "x" = "x$RABBITMQ_CTL_DIST_PORT_MAX" ] && RABBITMQ_CTL_DIST_PORT_MAX="$(($RABBITMQ_CTL_DIST_PORT_MIN + 10))"
|
|
|
|
|
2014-07-03 19:08:05 +08:00
|
|
|
[ "x" = "x$RABBITMQ_SERVER_ERL_ARGS" ] && RABBITMQ_SERVER_ERL_ARGS=${SERVER_ERL_ARGS}
|
|
|
|
[ "x" = "x$RABBITMQ_SERVER_START_ARGS" ] && RABBITMQ_SERVER_START_ARGS=${SERVER_START_ARGS}
|
|
|
|
[ "x" = "x$RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS" ] && RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS=${SERVER_ADDITIONAL_ERL_ARGS}
|
2016-05-20 20:43:35 +08:00
|
|
|
[ "x" = "x$RABBITMQ_SERVER_CODE_PATH" ] && RABBITMQ_SERVER_CODE_PATH=${SERVER_CODE_PATH}
|
2016-09-12 21:44:23 +08:00
|
|
|
[ "x" = "x$RABBITMQ_IGNORE_SIGINT" ] && RABBITMQ_IGNORE_SIGINT="true"
|
2016-09-13 01:40:08 +08:00
|
|
|
[ "xtrue" = "x$RABBITMQ_IGNORE_SIGINT" ] && RABBITMQ_IGNORE_SIGINT_FLAG="+B i"
|
2014-07-03 19:08:05 +08:00
|
|
|
|
2018-09-06 22:49:19 +08:00
|
|
|
if [ -n "$saved_RABBITMQ_PID_FILE" ] && \
|
|
|
|
[ "$saved_RABBITMQ_PID_FILE" != "$RABBITMQ_PID_FILE" ]
|
|
|
|
then
|
|
|
|
_rmq_env_pwarn 'RABBITMQ_PID_FILE was already set by the init script to:' \
|
|
|
|
"$saved_RABBITMQ_PID_FILE" \
|
|
|
|
'The value set in rabbitmq-env.conf is ignored because it would break the init script.'
|
|
|
|
|
|
|
|
RABBITMQ_PID_FILE="$saved_RABBITMQ_PID_FILE"
|
|
|
|
fi
|
|
|
|
|
2015-07-01 20:47:36 +08:00
|
|
|
[ "x" = "x$RABBITMQ_BOOT_MODULE" ] && RABBITMQ_BOOT_MODULE=${BOOT_MODULE}
|
|
|
|
|
2014-07-03 19:08:05 +08:00
|
|
|
##--- End of overridden <var_name> variables
|
2014-11-27 00:45:25 +08:00
|
|
|
|
Move most of shell scripts to Erlang code
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
2019-05-15 22:27:51 +08:00
|
|
|
_rmq_env_set_erl_libs()
|
|
|
|
{
|
|
|
|
if [ -n "$ERL_LIBS" ]
|
|
|
|
then
|
|
|
|
export ERL_LIBS="$RABBITMQ_HOME/plugins:$ERL_LIBS"
|
2015-10-20 21:42:59 +08:00
|
|
|
else
|
Move most of shell scripts to Erlang code
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
2019-05-15 22:27:51 +08:00
|
|
|
export ERL_LIBS="$RABBITMQ_HOME/plugins"
|
2015-08-31 17:26:39 +08:00
|
|
|
fi
|
Move most of shell scripts to Erlang code
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
2019-05-15 22:27:51 +08:00
|
|
|
}
|
2015-08-31 17:26:39 +08:00
|
|
|
|
2017-12-30 05:56:23 +08:00
|
|
|
run_escript()
|
|
|
|
{
|
|
|
|
escript="${1:?escript must be defined}"
|
|
|
|
shift
|
|
|
|
|
2023-12-30 12:55:17 +08:00
|
|
|
maybe_noinput="${1:?maybe_noinput must be defined}"
|
|
|
|
shift
|
|
|
|
|
Move most of shell scripts to Erlang code
A large part of the rabbitmq-server(8) and CLI scripts, both
Bourne-shell and Windows Batch versions, was moved to Erlang code and
the RabbitMQ startup procedure was reorganized to be closer to a regular
Erlang application.
A new application called `rabbitmq_prelaunch` is responsible for:
1. Querying the environment variables to initialize important
variables (using the new `rabbit_env` module in rabbitmq-common).
2. Checking the compatibility with the Erlang/OTP runtime.
3. Configuring Erlang distribution.
5. Writing the PID file.
The application is started early (i.e. it is started before `rabbit`).
The `rabbit` application runs the second half of the prelaunch sequence
at the beginning of the application `start()` function. This second
phase is responsible for the following steps:
1. Preparing the feature flags registry.
2. Reading and validating the configuration.
3. Configuring logging.
4. Running the various cluster checks.
In addition to this prelaunch sequence, the `rabbit` application start
procedure ends with a "postlaunch" sequence which takes care of
starting enabled plugins.
Thanks to this, RabbitMQ can be started with `application:start(rabbit)`
as any other Erlang application. The only caveats are:
* Mnesia must be stopped at the time `rabbit_prelaunch` is started,
and must remain stopped when `rabbit` is started, to allow the
Erlang distribution setup and cluster checks. `rabbit` takes care of
starting Mnesia.
* Likewise for Ra, because it relies on the `ra` application
environment to be configured.
Transitioning from scripts to Erlang code has the following benefits:
* RabbitMQ start behavior should be identical between Unix and
Windows. Also, features should be on par now. For instance, RabbitMQ
now writes a PID file on Windows, like it always did on Unix-based
systems.
* The difference between published packages and a development
environment are greatly reduced. In fact, we removed all the "if
this is a dev working copy, then ..." blocks.
As part of that, the `rabbit` application is now treated like its
plugins: it is packaged as an `.ez` archive and written to the
`plugins` directory (even though it is not technically a plugin).
Also in a development copy, the CLI is copied to the top-level
project. So when testing a plugin for instance, the CLI to use is
`sbin/rabbitmqctl` in the current directory, not the master copy in
`rabbit/scripts`.
* As a consequence of the previous two points, maintaining and testing
on Windows is now made easy. It should even be possible to setup CI
on Windows.
* There are less issues with paths containing non-US-ASCII characters,
which can happen on Windows because RabbitMQ stores its data in user
directories by default.
This process brings at least one more benefit: we now have early logging
during this prelaunch phase, which eases diagnostics and debugging.
There are also behavior changes:
* The new format configuration files used to be converted to an
Erlang-term-based file by the Cuttlefish CLI. To do that,
configuration schemas were copied to a temporary directory and the
generated configuration file was written to RabbitMQ data directory.
Now, Cuttlefish is used as a library: everything happens in memory.
No schemas are copied, no generated configuration is written to
disk.
* The PID file is removed when the Erlang VM exits.
* The `rabbit_config` module was trimmed significantly because most of
the configuration handling is done in `rabbit_prelaunch_conf` now.
* The RabbitMQ nodename does not appear on the command line, therefore
it is missing from ps(1) and top(1) output.
* The `rabbit:start()` function will probably behave differently in
some ways because it defers everything to the Erlang application
controller (instead of reimplementing it).
2019-05-15 22:27:51 +08:00
|
|
|
_rmq_env_set_erl_libs
|
|
|
|
|
2023-12-30 12:55:17 +08:00
|
|
|
tmp_erl_flags="-boot $CLEAN_BOOT_FILE $RABBITMQ_CTL_ERL_ARGS -kernel inet_dist_listen_min $RABBITMQ_CTL_DIST_PORT_MIN -kernel inet_dist_listen_max $RABBITMQ_CTL_DIST_PORT_MAX"
|
|
|
|
|
|
|
|
if [ "$maybe_noinput" = 'noinput' ]
|
|
|
|
then
|
|
|
|
tmp_erl_flags="-noinput $tmp_erl_flags"
|
|
|
|
fi
|
|
|
|
|
|
|
|
ERL_FLAGS="$tmp_erl_flags" "$escript" "$@"
|
|
|
|
|
|
|
|
unset tmp_erl_flags
|
2017-12-30 05:56:23 +08:00
|
|
|
}
|
|
|
|
|
2015-04-08 17:52:50 +08:00
|
|
|
RABBITMQ_ENV_LOADED=1
|
|
|
|
|
2014-11-27 00:45:25 +08:00
|
|
|
# Since we source this elsewhere, don't accidentally stop execution
|
|
|
|
true
|