| 
									
										
										
										
											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
										 |  |  | ## | 
					
						
							| 
									
										
										
										
											2020-03-10 22:36:02 +08:00
										 |  |  | ##  Copyright (c) 2007-2020 VMware, Inc. or its affiliates.  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 | 
					
						
							|  |  |  | [ "x" = "x$RABBITMQ_CONF_ENV_FILE" ] && RABBITMQ_CONF_ENV_FILE=${CONF_ENV_FILE} | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | if [ -f "${RABBITMQ_CONF_ENV_FILE}" ]; then | 
					
						
							| 
									
										
										
										
											2020-04-06 19:00:08 +08:00
										 |  |  |     CONF_ENV_FILE_PHASE=rabbitmq-env | 
					
						
							|  |  |  |     . ${RABBITMQ_CONF_ENV_FILE} || true | 
					
						
							| 
									
										
											  
											
												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 | 
					
						
							| 
									
										
										
										
											2021-02-10 19:35:12 +08:00
										 |  |  | SERVER_ERL_ARGS=" +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_main="${1:?escript_main must be defined}" | 
					
						
							|  |  |  |     shift | 
					
						
							|  |  |  |     escript="${1:?escript 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 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2018-10-12 04:30:49 +08:00
										 |  |  |     # Important: do not quote RABBITMQ_CTL_ERL_ARGS as they must be | 
					
						
							|  |  |  |     # word-split | 
					
						
							| 
									
										
										
										
											2018-01-03 03:53:24 +08:00
										 |  |  |     # shellcheck disable=SC2086 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     exec erl +B \ | 
					
						
							| 
									
										
										
										
											2018-10-12 04:30:49 +08:00
										 |  |  |         -boot "$CLEAN_BOOT_FILE" \ | 
					
						
							| 
									
										
										
										
											2017-12-30 05:56:23 +08:00
										 |  |  |         -noinput -noshell -hidden -smp enable \ | 
					
						
							| 
									
										
										
										
											2018-02-16 00:30:59 +08:00
										 |  |  |         $RABBITMQ_CTL_ERL_ARGS \ | 
					
						
							| 
									
										
										
										
											2020-06-25 21:20:23 +08:00
										 |  |  |         -kernel inet_dist_listen_min "$RABBITMQ_CTL_DIST_PORT_MIN" \ | 
					
						
							|  |  |  |         -kernel inet_dist_listen_max "$RABBITMQ_CTL_DIST_PORT_MAX" \ | 
					
						
							| 
									
										
										
										
											2017-12-30 05:56:23 +08:00
										 |  |  |         -run escript start \ | 
					
						
							|  |  |  |         -escript main "$escript_main" \ | 
					
						
							|  |  |  |         -extra "$escript" "$@" | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											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 |