... which are added by debhelper. In this case, this is
init-system-helpers which is added by dh-systemd.
While here, bump the standard version to 3.9.6.
(cherry picked from commit 851561953a)
Recent openSUSE releases have been migrated to systemd so use the
%{suse_version} macro to detect if we are building on openSUSE
so we can include the necessary systemd files and also perform the
needed systemd steps. This also defines the 'suse_version' to 1315
which is what openSUSE Leap 42.x use. This also drops the buggy rhel7
conditional for the sysvinit script and use another 'find' command
instead. The previous condition was wrong since it would also try
to include the sysvinit file on openSUSE and Fedora which do not
define the %rhel macro and as such the 0 < 7 conditional was always
true.
(cherry picked from commit 2211e5fe44)
In the old release build script, Erlang is already provided. However in
CI, Erlang is installed later in the Makefile recipe. Thus, display its
version only once we are sure Erlang is available.
(cherry picked from commit 5cb41b9434)
This should help us diagnose situations where the version of Erlang used
to compile is greater than the minimum supported.
(cherry picked from commit 679518f911)
The previous patch was meant to make it clear that an unprivileged user
(other than `rabbitmq`) shouldn't run rabbitmq-plugins.
Unfortunately, it broke the script when called by root, because the
real script was executed as `rabbitmq`. This user doesn't have write
permissions to `/etc/rabbitmq` by default.
Now, rabbitmq-plugins' wrapper must be executed as root and so is the
real script. This should fix the problem described above.
[#149840153]
systemd considers that, when the ExecStop commands exit, the service is
stopped. If there are remaining processes in the cgroup, they are
killed.
Unfortunately, `rabbitmqctl stop` doesn't wait for the Erlang VM to
exit, it just notifies RabbitMQ to stop. Because it doesn't wait,
systemd kills other processes such as `erl_child_setup`. When this
happens, the Erlang VM crashes (because it can't reach `erl_child_setup`
anymore) and the service enters the failed state in systemd. Note the
"erl_child_setup closed" message in the following output:
[root@ip-172-31-29-47 package-testing]# systemctl status rabbitmq-server
● rabbitmq-server.service - RabbitMQ broker
Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; disabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Mon 2017-07-31 14:54:42 UTC; 1s ago
Process: 26763 ExecStop=/usr/sbin/rabbitmqctl stop (code=exited, status=0/SUCCESS)
Process: 26398 ExecStart=/usr/sbin/rabbitmq-server (code=exited, status=1/FAILURE)
Main PID: 26398 (code=exited, status=1/FAILURE)
Status: "Initialized"
Jul 31 14:54:30 ip-172-31-29-47 rabbitmq-server[26398]: completed with 0 plugins.
Jul 31 14:54:40 ip-172-31-29-47 systemd[1]: Stopping RabbitMQ broker...
Jul 31 14:54:41 ip-172-31-29-47 rabbitmqctl[26763]: Stopping and halting node 'rabbit@ip-172-31-29-47'
Jul 31 14:54:41 ip-172-31-29-47 rabbitmq-server[26398]: Gracefully halting Erlang VM
Jul 31 14:54:41 ip-172-31-29-47 rabbitmq-server[26398]: erl_child_setup closed
Jul 31 14:54:42 ip-172-31-29-47 rabbitmq-server[26398]: Crash dump is being written to: erl_crash.dump...done
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: rabbitmq-server.service: main process exited, code=exited, status=1/FAILURE
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: Stopped RabbitMQ broker.
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: Unit rabbitmq-server.service entered failed state.
Jul 31 14:54:42 ip-172-31-29-47 systemd[1]: rabbitmq-server.service failed.
Now, we add a second ExecStop which simply waits for the Erlang VM PID
to disappear. This looks to fix the issue.
[#149807109]
For some reason, the rabbitmq-plugins command could be run
from arbitrary user, which would result in errors unable to
access a cookie file or plugins configuration files.
Changed to work the same way as rabbitmqctl - require root
or rabbitmq user.
[Fixes#149425921]
The erlang-* 1:16.b.3 packages family (note the absence of the package
revision) was only partially uploaded to the Erlang Solutions Debian
repository... For instance, we have erlang-nox 1:16.b.3 and 1:16.b.3-3,
but only erlang-base 1:16.b.3-3 :-/
[#131645781]
We use mk-build-deps(1) from the `devscripts` package to help us with
this. This helper script looks at `debian/control` and creates a
meta-package which depends on the build dependencies. Then we only have to
install it to get those dependencies.
We only do this if `$(INSTALL_BUILD_DEPS)` is set to `yes`. We want to
use this feature in CI, but not with the old build script where we cheat
a lot around Erlang and Elixir packages.
[#131645781]
Some parts of #21 have not been added to the stable branch. This change
fixes the issue by adding missing changes to rabbitmq-server-ha.ocf and
also fixing rabbitmq-server.ocf
For some reason some changes were lost from #21, adding back those.
The original PR message:
This enables to change the limit of open files, as the default on
distributions is usually too low for rabbitmq. Default is 65535.
It would be helpful to see rabbit's output when it exits with non-zero
status code. The log level is left at info, as it might be business as
usual that a node is not running rabbit. The -q switch prevents the
output from being logged if the return value is zero.
The `PRODUCTVERSION` must be four integers. So try to replace
everything following the first three integers in the the
semver-formatted `$(VERSION)` by `.0`. For instance if `$(VERSION)` is
`3.6.8+1.g1dcb221`, `PRODUCTVERSION` will be set to `3.6.8.0`.
This should make Windows installer builds successful out-of-the-box.
This is still possible to override this behavior by setting the
`$(PRODUCT_VERSION)` Make variable.
[#142391637]
This boot script is required by escript(1). Without it, escript(1) fails
with the following error:
{"init terminating in do_boot",{'cannot get bootfile','start_clean.boot'}}
init terminating in do_boot ()
[#141679931]
(cherry picked from commit 7ffe744d66)