rabbitmq-server/scripts/rabbitmq-defaults.bat

@echo off

set SASL_BOOT_FILE=start_sasl
set CLEAN_BOOT_FILE=start_clean
set BOOT_MODULE=rabbit

if "!RABBITMQ_BASE!"=="" (
    set RABBITMQ_BASE=!APPDATA!\RabbitMQ
) else (
    set RABBITMQ_BASE=!RABBITMQ_BASE:"=!
)

if not exist "!RABBITMQ_BASE!" (
    mkdir "!RABBITMQ_BASE!"
)

set CONF_ENV_FILE=!RABBITMQ_BASE!\rabbitmq-env-conf.bat
rabbitmq-defaults.bat and rabbitmq-echopid.bat: Fix line ending 2015-11-04 01:25:10 +08:00			`@echo off`

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			`set SASL_BOOT_FILE=start_sasl`
Run escript and use RABBITMQ_CTL_ERL_ARGS env variable Fixes #1461 2017-12-30 05:56:23 +08:00			`set CLEAN_BOOT_FILE=start_clean`
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			`set BOOT_MODULE=rabbit`
rabbitmq-defaults.bat and rabbitmq-echopid.bat: Fix line ending 2015-11-04 01:25:10 +08:00
			`if "!RABBITMQ_BASE!"=="" (`
			`set RABBITMQ_BASE=!APPDATA!\RabbitMQ`
Remove short name formatting fix missing quote in mkdir argument to handle directories with spaces properly on Windows Ensure paths are double-quoted when necessary Ensure all win32 paths have forward slashes. Use more typical escaping of double quotes Do not convert to a binary as that has bad effects when the msg store dir base has extended ASCII characters, as when setting RABBITMQ_BASE to C:/ProgramData/Tést Directory (frazzle)/RabbitMQ Add "t" modifier to format strings for values that may be unicode Remove use of unquote as it only works when the second arg is not double-quoted when called, but that version fails on paths with spaces. De-quote ALL THE THINGS Update rabbitmq-components.mk (cherry picked from commit a515903662566e0fc158918bc1c42fc1a0a8384a) Log file management suite: adapt to Lager 3.8 I observed no functional changes around log rotation. These assertions depend on internal file management aspects of Lager, so let's update them and see. References #2068, #2059. (cherry picked from commit d6e7c3841c5f01933e9182da1701bd2ac74eb1ff) (cherry picked from commit 6a9eb18ca1f1f3d5166e923f54f4ed349a1b95a2) Replace dequote function with replace syntax, which works with unicode characters 2019-08-06 23:29:23 +08:00			`) else (`
			`set RABBITMQ_BASE=!RABBITMQ_BASE:"=!`
rabbitmq-defaults.bat and rabbitmq-echopid.bat: Fix line ending 2015-11-04 01:25:10 +08:00			`)`

Create directories and files on Windows before conversion to short filenames If the directory or file does not exist before RabbitMQ starts, we can't let RabbitMQ create it, otherwise, it's created with its short filename, not its long one. With this new correction, we can "escape" all variables instead of only RABBITMQ_BASE. Fixes #493. 2016-01-27 01:42:57 +08:00			`if not exist "!RABBITMQ_BASE!" (`
			`mkdir "!RABBITMQ_BASE!"`
			`)`
Use short filenames in Windows startup scripts On Windows, cmd.exe and batch scripts do not support Uniode apparently. However, Windows uses UTF-16 to encode filenames one disk. In batch scripts, filenames are converted to some one-byte-wide charset. Once passed to Erlang and RabbitMQ, those filenames are incorrect. In particular, the management UI is unhappy because filenames obviously contain invalid UTF-8 characters. Using short filenames makes sure filename only contain US-ASCII characters. To convert them, we use "for" expansion. At the same time, filenames are made absolute. It works even better than realpath.exe because the latter also converts filenames to another charset again. Fixe #493. 2015-12-14 20:52:47 +08:00
Override CONF_ENV_FILE with RABBITMQ_CONF_ENV_FILE 2016-04-05 20:58:36 +08:00			`set CONF_ENV_FILE=!RABBITMQ_BASE!\rabbitmq-env-conf.bat`