| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Here is a summary of RabbitMQ signal handling:
== SIGTERM ==
After #2180, `rabbit` is a regular Erlang application and
`application:stop(rabbit)` terminates RabbitMQ gracefully. This means
that `init:stop()` shuts the service down properly. Therefore, the
default handling of SIGTERM, which calls `init:stop()`, is correct.
rabbitmq-server(8) already relies on this mechanism.
This commit restores the default signal handler which already does the
right thing. No need to do it ourselves.
== SIGHUP and SIGTSTP ==
SIHGUP is usually used to reload the configuration without restarting
the service and/or reopen log files after log file rotation. SIGTSTP is
sent when a user types Ctrl+Z to pause a program and get back to the
shell. Both signals have common behavior we can't satisfy currently.
Note that we don't handle SIGCONT which is the one used to resume a
program after SIGTSTP. The system default behavior is already good (the
signal is discarded).
To be consistent with rabbitmq-server(8) signal handling, the signals
are ignored until we can do something about them.
== SIGQUIT ==
This signal is meant to terminate the process immediately and
create a core dump. If possible, temporary files should even be kept
around. The default behavior in Erlang is to call `erlang:halt()` which
is a sane default: we should not stop RabbitMQ gracefully.
This commit restores this behavior.
== SIGUSR1 and SIGUSR2 ==
Erlang uses SIGUSR1 to crash the VM and create an `erl_crash.dump`
file. We already used this in the past to debug RabbitMQ. Again, a sane
default.
This commit restores this behavior.
== Other signals ==
We keep the default behavior of all other signals. None of them are
meant to stop the program gracefully anyway. If a user wants to stop
RabbitMQ, he will already use the common accepted signal for this
purpose (i.e. SIGTERM).
Another change in this commit is the way we setup the signal handler:
* We don't replace the default Erlang signal handler, just add ours.
* We do it very early in rabbitmq_prelaunch. Like other things
configured by this application, we do not uninstall the handler when
the application is stopped.
This reverts:
* commit 6a4d2721d06b8c70a36e29e6c51bbef6608def55
* commit fa607e4a25d6142bb17a90b44ef757572a923c09
|
| |\
| |
| | |
Speedup execution of bootsteps
|
| |/
|
|
|
|
|
|
|
| |
filtering and grouping of MFA specifications. This
improves speed of execution by factor of 2N, where
N is number of attributes per step, matching the
passed `AttributeName`. Dropping constants, overall
time complexity remains O(N), but cant be neglected
for modules with multiple bootstep attributes.
|
| |
|
|
|
|
| |
See https://github.com/rabbitmq/discussions/issues/62 for details.
Rates mode is how it is controlled but this leftover example
was around several years after the switch.
|
| | |
|
| | |
|
| |\
| |
| | |
rabbitmq_prelaunch: Fix all warnings reported by Dialyzer
|
| |/
|
|
|
|
| |
They are all return values being unmatched. Many were related to list
comprehensions being used as a loop mechanism but the result was unused.
These list comprehensions were replaced by lists:foreach/2.
|
| | |
|
| |\
| |
| | |
Small refactor for 15dfe7b1bf63c6f6b9940738b219f08bcc241cbd
|
| |/
|
|
| |
In `rabbit_common/mk/rabbitmq-run.mk` the default is to use `debug` for the file log level. However, prior to this change that log level is not applied.
|
| |\
| |
| | |
Convert systemd notification to prelaunch steps
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce the rabbit_boot_state module, which extracts boot state
management out of rabbit_prelaunch.
External boot state listeners, such as systemd, now live under the
rabbit_boot_state_sup supervisor, which dispatches boot state updates to
all of its children as a gen_server cast.
Additionally:
- the systemd listener now reads the NOTIFY_SOCKET env var directly,
rather than through rabbit_env, to avoid the need to wait for the
rabbit_env context to initialize
- the sytemd listener now only checks for the sd_notify module and
NOTIFY_SOCKET env var once upon startup, exiting gracefully when not
needed
- systemd related log messages are now routed through lager
|
| |\
| |
| | |
Various fixes post #2180
|
| | | |
|
| |/
|
|
|
| |
The latter is only ever called by the former, so there is no need to
split them.
|
| |\
| |
| | |
unit_log_config_SUITE: Adapt after fixes to rabbit_lager
|
| |/
|
|
|
|
| |
See:
* commit 169eeeb426b1c71e5b4e81f8fa813cab9570247a
* commit 15dfe7b1bf63c6f6b9940738b219f08bcc241cbd
|
| |\
| |
| |
| |
| | |
rabbitmq/fix-logging-after-issue2180-related-changes
Fix logging after #2180-related changes
|
| | |
| |
| |
| |
| |
| |
| |
| | |
After changing the module to take into account the log level set from
the `$RABBITMQ_LOG` environment variable, I broke the ability to set it
from the configuration file.
This should work again.
|
| |/
|
|
|
|
|
|
| |
For the other backends, go back to "\n" only.
This fixes an issue where the log file had a mix of "\n" and "\r\n" as
newlines characters. This was visible through "^M" characters at the end
of each line.
|
| |\
| |
| | |
Handle and raise protocol error for absent queues assumed to be alive
|
| |/ |
|
| | |
|
| | |
|
| |
|
|
|
| |
when working with definition import, replacement
or cleanup.
|
| |\
| |
| | |
Move all RabbitMQ-specific environment variables to `rabbit_env`
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
... instead of calling rabbit_nodes:name_type(). The latter now uses the
context to return the name type of the current node (instead of the
environment variable which may not be set). However, this function is
executed in the context of the CLI which does not start
rabbit_prelaunch. Therefore, there is no context to get the name type
from.
Anyway, the name type should be determined based on the node name we are
about to impersonate. So use the argument to deduce the name type.
|
| |/
|
|
|
|
|
|
|
|
| |
The reading of `$NOTIFY_SOCKET` is also moved at the same time. This is
in preparation of the work around start/stop status.
There is an associated commit in rabbitmq-common to update `rabbit_env`
and record the origin of each variable.
[#170149339]
|
| |
|
|
|
|
|
|
|
| |
* Only log the intent to import for categories that are not empty/missing
* Log how many entities will be imported
Current logging frequency is reasonable for occasional manual
or automated imports but with continuous automated imports
(say, a hot standby) it is too excessive.
|
| |
|
|
|
|
|
|
|
|
| |
rabbit_amqqueue:lookup/1 already supports lists of keys
but it makes less sense for rabbit_exchange:lookup/1.
This introduces a uniform API element that can be used to look up
N entities by key while preserving the historically accumulated
difference that stems from the common access patterns
for each entity type.
|
| |
|
|
| |
like rabbit_amqqueue does
|
| | |
|
| |
|
|
|
| |
As previous 3.7.x do not have the function the test relies on.
Note that the change is otherwise safe for them.
|
| |\
| |
| | |
Ignore SIGUSR2 signal as well
|
| |/
|
|
| |
Fixes #2222
|
| |\
| |
| | |
Override OTP handlers to gracefully shut down on SIGTERM, SIGQUIT
|
| | |
| |
| |
| |
| |
| |
| |
| | |
otherwise the default handler will terminate the runtime.
Closes #2222.
Pair: @vanlightly.
|
| |\ \
| |/
|/| |
Introduce a persistent internal cluster ID
|
| | |
| |
| |
| | |
Pair: @vanlightly
|
| |/
|
|
|
|
|
|
|
|
|
| |
That the operator cannot and are not supposed to control.
The ID is cluster-wide and stored as a global runtime parameter to make
sure it is replicated across all nodes.
It is intentionally excluded from imported definitions because it is not
meant to be reused.
This ID would be useful in several features/plugins under development.
|
| | |
|
| |\
| |
| | |
Fix bad type of result of ack function.
|
| | | |
|
| |/ |
|
| |\
| |
| | |
rabbit: Change start_apps/2 to call application:ensure_all_started/2
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
.. instead of reinventing about the same logic.
start_apps/2 is not called to start the `rabbit` application anymore (it
is started as a normal Erlang application now). It means it's only used
to start plugins which are also supposed to be regular Erlang
applications.
It runs boot steps unconditionally as well (because this function never
starts `rabbit).
One difference with the previous code is that the previous code started
all loaded applications. This seemed unnecessary and even caused issues
with testsuites where some applications were loaded like `rabbitmqctl`
but were not meant to be started.
Another difference is that before, all boot steps were executed at once,
then all plugins were started. Now, to improve consistency and make sure
that a dependency is fully ready before a plugin which depends on it
starts, for each application we execute the boot steps then start it,
before moving to the next.
[#170870798]
|
| |\
| |
| | |
rabbit: Fix plugins' run_boot_steps() vs. start order
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before `rabbit` startup code was rewritten as part of
rabbitmq/rabbitmq-server#2180 to make it closer to a regular Erlang
application, plugins' boot steps were executed before plugins were
started.
This commit restores this behavior. Indeed the initial patch inverted
them by starting the plugins first, then executed the boot steps.
It also brings another improvement in the process: a dependency has its
boot steps executed and is started before a plugin which depends on it
is considered. This should improve consistency.
Note that the `start_apps/2` function, which is run when a user enables
a plugin at runtime must be improved as well. There is a work in
progress in rabbitmq/rabbitmq-server#2219.
|
| |
|
|
|
| |
Those are all the testsuites which take more than 5 minutes in
Concourse.
|
