2008-07-03 20:35:11 +08:00
@ echo off
2020-07-10 21:31:17 +08:00
REM This Source Code Form is subject to the terms of the Mozilla Public
REM License, v. 2.0. If a copy of the MPL was not distributed with this
REM file, You can obtain one at https://mozilla.org/MPL/2.0/.
2008-07-03 20:35:11 +08:00
REM
2020-03-10 22:36:02 +08:00
REM Copyright (c) 2007-2020 VMware, Inc. or its affiliates. All rights reserved.
2008-07-03 20:35:11 +08:00
REM
2009-10-29 17:49:05 +08:00
setlocal
2010-01-31 20:28:22 +08:00
rem Preserve values that might contain exclamation marks before
rem enabling delayed expansion
2010-02-08 15:55:58 +08:00
set TDP0 = %~dp0
2010-01-31 20:36:31 +08:00
set STAR = %*
2019-08-06 23:29:23 +08:00
set CONF_SCRIPT_DIR = %~dp0
2010-01-31 20:28:22 +08:00
setlocal enabledelayedexpansion
2017-01-12 21:28:47 +08:00
setlocal enableextensions
if ERRORLEVEL 1 (
echo " Failed to enable command extensions! "
exit /B 1
)
2010-01-31 20:28:22 +08:00
2015-06-24 11:42:49 +08:00
REM Get default settings with user overrides for (RABBITMQ_)<var_name>
REM Non-empty defaults should be set in rabbitmq-env
2015-10-31 00:20:04 +08:00
call " %TDP0% \rabbitmq-env.bat " %~n0
2014-03-14 00:28:08 +08:00
2010-01-31 20:28:22 +08:00
if not exist " !ERLANG_HOME! \bin\erl.exe " (
2008-07-03 20:35:11 +08:00
echo .
echo ******************************
2009-11-26 02:14:26 +08:00
echo ERLANG_HOME not set correctly.
2008-07-03 20:35:11 +08:00
echo ******************************
echo .
echo Please either set ERLANG_HOME to point to your Erlang installation or place the
echo RabbitMQ server distribution in the Erlang lib folder.
echo .
2015-02-26 02:19:16 +08:00
exit /B 1
2008-07-03 20:35:11 +08:00
)
2018-05-21 19:26:01 +08:00
set RABBITMQ_DEFAULT_ALLOC_ARGS = +MBas ageffcbf +MHas ageffcbf +MBlmbcs 512 +MHlmbcs 512 +MMmcs 30
2014-04-28 06:49:24 +08:00
set RABBITMQ_START_RABBIT =
2015-12-14 19:04:21 +08:00
if " !RABBITMQ_ALLOW_INPUT! " == " " (
set RABBITMQ_START_RABBIT = !RABBITMQ_START_RABBIT! -noinput
)
2014-04-28 06:49:24 +08:00
if " !RABBITMQ_NODE_ONLY! " == " " (
2015-12-14 19:04:21 +08:00
set RABBITMQ_START_RABBIT = !RABBITMQ_START_RABBIT! -s " !RABBITMQ_BOOT_MODULE! " boot
2014-04-28 06:49:24 +08:00
)
2016-02-05 21:26:21 +08:00
set ENV_OK = true
2016-03-19 00:26:04 +08:00
CALL : check_not_empty " RABBITMQ_BOOT_MODULE " !RABBITMQ_BOOT_MODULE!
2016-02-05 21:26:21 +08:00
if " !ENV_OK! " == " false " (
EXIT /b 78
2015-07-12 20:15:40 +08:00
)
2015-06-04 01:06:59 +08:00
2019-08-29 00:38:36 +08:00
if " !RABBITMQ_ALLOW_INPUT! " == " " (
set ERL_CMD = erl.exe
) else (
set ERL_CMD = werl.exe
)
" !ERLANG_HOME! \bin\!ERL_CMD! " ^
2014-04-28 06:49:24 +08:00
!RABBITMQ_START_RABBIT! ^
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
-boot " !SASL_BOOT_FILE! " ^
2008-07-03 20:35:11 +08:00
+W w ^
2018-05-21 19:26:01 +08:00
!RABBITMQ_DEFAULT_ALLOC_ARGS! ^
2010-01-31 20:28:22 +08:00
!RABBITMQ_SERVER_ERL_ARGS! ^
2014-06-20 16:13:32 +08:00
!RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS! ^
2010-01-31 20:28:22 +08:00
!RABBITMQ_SERVER_START_ARGS! ^
Switch from Lager to the new Erlang Logger API for logging
The configuration remains the same for the end-user. The only exception
is the log root directory: it is now set through the `log_root`
application env. variable in `rabbit`. People using the Cuttlefish-based
configuration file are not affected by this exception.
The main change is how the logging facility is configured. It now
happens in `rabbit_prelaunch_logging`. The `rabbit_lager` module is
removed.
The supported outputs remain the same: the console, text files, the
`amq.rabbitmq.log` exchange and syslog.
The message text format slightly changed: the timestamp is more precise
(now to the microsecond) and the level can be abbreviated to always be
4-character long to align all messages and improve readability. Here is
an example:
2021-03-03 10:22:30.377392+01:00 [dbug] <0.229.0> == Prelaunch DONE ==
2021-03-03 10:22:30.377860+01:00 [info] <0.229.0>
2021-03-03 10:22:30.377860+01:00 [info] <0.229.0> Starting RabbitMQ 3.8.10+115.g071f3fb on Erlang 23.2.5
2021-03-03 10:22:30.377860+01:00 [info] <0.229.0> Licensed under the MPL 2.0. Website: https://rabbitmq.com
The example above also shows that multiline messages are supported and
each line is prepended with the same prefix (the timestamp, the level
and the Erlang process PID).
JSON is also supported as a message format and now for any outputs.
Indeed, it is possible to use it with e.g. syslog or the exchange. Here
is an example of a JSON-formatted message sent to syslog:
Mar 3 11:23:06 localhost rabbitmq-server[27908] <0.229.0> - {"time":"2021-03-03T11:23:06.998466+01:00","level":"notice","msg":"Logging: configured log handlers are now ACTIVE","meta":{"domain":"rabbitmq.prelaunch","file":"src/rabbit_prelaunch_logging.erl","gl":"<0.228.0>","line":311,"mfa":["rabbit_prelaunch_logging","configure_logger",1],"pid":"<0.229.0>"}}
For quick testing, the values accepted by the `$RABBITMQ_LOGS`
environment variables were extended:
* `-` still means stdout
* `-stderr` means stderr
* `syslog:` means syslog on localhost
* `exchange:` means logging to `amq.rabbitmq.log`
`$RABBITMQ_LOG` was also extended. It now accepts a `+json` modifier (in
addition to the existing `+color` one). With that modifier, messages are
formatted as JSON intead of plain text.
The `rabbitmqctl rotate_logs` command is deprecated. The reason is
Logger does not expose a function to force log rotation. However, it
will detect when a file was rotated by an external tool.
From a developer point of view, the old `rabbit_log*` API remains
supported, though it is now deprecated. It is implemented as regular
modules: there is no `parse_transform` involved anymore.
In the code, it is recommended to use the new Logger macros. For
instance, `?LOG_INFO(Format, Args)`. If possible, messages should be
augmented with some metadata. For instance (note the map after the
message):
?LOG_NOTICE("Logging: switching to configured handler(s); following "
"messages may not be visible in this log output",
#{domain => ?RMQLOG_DOMAIN_PRELAUNCH}),
Domains in Erlang Logger parlance are the way to categorize messages.
Some predefined domains, matching previous categories, are currently
defined in `rabbit_common/include/logging.hrl` or headers in the
relevant plugins for plugin-specific categories.
At this point, very few messages have been converted from the old
`rabbit_log*` API to the new macros. It can be done gradually when
working on a particular module or logging.
The Erlang builtin console/file handler, `logger_std_h`, has been forked
because it lacks date-based file rotation. The configuration of
date-based rotation is identical to Lager. Once the dust has settled for
this feature, the goal is to submit it upstream for inclusion in Erlang.
The forked module is calld `rabbit_logger_std_h` and is based
`logger_std_h` in Erlang 23.0.
2021-01-13 00:55:27 +08:00
-syslog logger [] ^
-syslog syslog_error_logger false ^
2010-01-31 20:36:31 +08:00
!STAR!
2009-10-29 17:49:05 +08:00
2018-10-18 21:29:33 +08:00
if ERRORLEVEL 1 (
2019-08-30 21:21:31 +08:00
exit /B %ERRORLEVEL%
2018-10-18 21:29:33 +08:00
)
2016-02-05 21:26:21 +08:00
EXIT /B 0
: check_not_empty
2016-03-09 20:06:22 +08:00
if " %~2 " == " " (
2016-03-08 19:29:07 +08:00
ECHO " Error: ENV variable should be defined: %1 . Please check rabbitmq-env and rabbitmq-defaults, and !RABBITMQ_CONF_ENV_FILE! script files. Check also your Environment Variables settings "
2016-02-05 21:26:21 +08:00
set ENV_OK = false
2016-03-19 00:26:04 +08:00
EXIT /B 78
2016-02-05 21:26:21 +08:00
)
EXIT /B 0
2009-10-29 17:49:05 +08:00
endlocal
2010-01-31 20:28:22 +08:00
endlocal
2017-01-12 21:28:47 +08:00
endlocal
