If we use xargs(1) to call tar(1), we are limited by the number of
arguments we can put on the command line. Since we switch to use
directories to "package" plugins instead of .ez archives, the number of
files exploded. This led to incomplete generic-unix archives (i.e. some
plugins and CLI scripts were missing for instance).
Now, the list of files is written to a manifest, exactly like we do it
to create the source archive.
Console output is handled in the SysV init scripts consistently (no more
differences between the Debian and RPM packages). See the previous
commit.
This fixes an issue for users who used to define $RABBITMQ_LOG_BASE in
the environment and called this script directly (i.e. not using the SysV
init scripts). Before commit 4b7048205d
(which made it to RabbitMQ 3.8.4), `rabbitmq-script-wrapper` took
$RABBITMQ_LOG_BASE from rabbitmq-env(8) or the environment. After the
mentionned commit, $RABBITMQ_LOG_BASE was hard-coded to setup console
redirection (in the case of Debian only) because rabbitmq-env(8) didn't
have the variable anymore and thus was not sourced.
For those users, it meant they couldn't override $RABBITMQ_LOG_BASE in
the environment and call this script, even if they wanted to change the
location of RabbitMQ actual log files.
Now that console redirection is handled by the SysV init scripts, we can
get rid of that code in `rabbitmq-script-wrapper`.
Fixesrabbitmq/rabbitmq-server-release#131.
Historically we were using $RABBITMQ_LOG_BASE to configure the
redirection. The variable default value was set in rabbitmq-env(8) which
made it to the SysV init scripts because they sourced it in the past.
This was removed in commit 4b7048205d as
part of the transition to rabbit_env/rabbitmq_prelaunch to handle the
environment in the Erlang code (see rabbitmq/rabbitmq-server#2180).
Instead, the value of $RABBITMQ_LOG_BASE was hard-coded. Unfortunately,
this caused a regression because users couldn't configure it from
rabbitmq-env.conf anymore (only /etc/default/rabbitmq-server).
Anyway, the semantic was slightly incorrect: $RABBITMQ_LOG_BASE is used
in the configuration of log files RabbitMQ is responsible for. Console
redirection is the responsibility of the SysV init scripts and the
package which creates the directory and set ownership.
This patch introduces a new $RABBITMQ_SERVER_CONSOLE_OUTPUT_DIR variable
which is specific to the SysV init scripts. For backward compatibility,
we still look at the value of $RABBITMQ_LOG_BASE if the user set it in
/etc/default/rabbitmq-server.
While here, align the Debian SysV init script behavior with the RPM
version of the script: console redirection is always configured in the
SysV init script, not in `rabbitmq-script-wrapper`. A subsequent commit
will take care of cleaning `rabbitmq-script-wrapper`.
The solution to redirect output when using start-stop-daemon(8) was
taking from the following post:
https://stackoverflow.com/questions/8251933/how-can-i-log-the-stdout-of-a-process-started-by-start-stop-daemon
References rabbitmq/rabbitmq-server-release#131.
After starting the RabbitMQ server process, the startup script will
wait for the server to start by calling `rabbitmqctl wait` and will
time out after 10 s.
The startup time of the server depends on how quickly the Mnesia
database becomes available and the server will time out after
`mnesia_table_loading_retry_timeout` ms times
`mnesia_table_loading_retry_limit` retries. By default this wait is
30,000 ms times 10 retries, i.e. 300 s.
The mismatch between these two timeout values might lead to the
startup script failing prematurely while the server is still waiting
for the Mnesia tables.
This change introduces variable `RABBITMQ_STARTUP_TIMEOUT` and the
`--timeout` option into the startup script. The default value for this
timeout is set to 10 minutes (600 seconds).
This change also updates the systemd service file to match the timeout
values between the two service management methods.
Signed-off-by: Nicolas Bock <nicolas.bock@canonical.com>
This was used to define `$RABBITMQ_LOG_BASE`, but this variable is no
longer define there.
rabbitmq-env would also load `rabbitmq-env.conf` which could redefine
`$RABBITMQ_LOG_BASE`, but this is a corner case and doesn't fit
packaging well: packages already prepare a location for log files and
will clean this location up on removal.
Now, we set `$RABBITMQ_LOG_BASE` value in those scripts and get rid of
rabbitmq-env load.
but not 23.0. By being overly conservative with minor version numbers
we repeatedly run into the same problem:
* A RabbitMQ release comes out and marks 22.1 as unsupported
* Erlang/OTP 22.1 comes out the next day
* Debian users cannot install this combination which the docs unintentionally
recommend by using the "latest 22" apt compoonent.
Minor versions of 21.x and 22.x have been compatible with the original
major release, so let's switch to a more optimistic version range
unless we have evidence of incompatibilities in recent minor releases.
Exactly like we do it with `$HOME`, this is to exercices our hack to
make mix(1) work offline.
Starting with Elixir 1.9.0, mix(1) accepts a `$MIX_HOME` variable to
point it to its own central directory. If it's not defined, it uses
first the `$XDG_DATA_HOME` and `$XDG_CONFIG_HOME` Freedesktop.org
variables. Then it uses `$HOME`.
So here, we specify those two variables explicitely to make sure they do
not disturb the build process.
Before this patch, the package handled the upgrade like this:
1. It stopped the service in `%pre` so that the service doesn't run with
an upgrade in progress.
2. It used the `try-restart` command in `%postun` to restart the service.
`try-restart` only restarts the service if it is already running. This
makes sense when used alone: if the service was not running before
an upgrade, you don't want the service to be started in your back.
Unfortunately, this was broken because the service was stopped before
the upgrade, preventing `try-restart` to do its job. This led to a
service left stopped after an upgrade.
Now the new approach is the following one:
1. It records in `/var/lib/rabbitmq` if the service is running in
`%pre`.
2. It stops the service in `%pre`.
3. It restarts the service in `%post` if it finds the record made
in step 1.
We use `restart` in step 3, not just `start`, just in case the service
was already restarted in the middle of the upgrade by e.g. a
configuration system.
Restart is handled in `%post`, not `%postun`, because it is also covers a
reinstall of the same version. This is ok because the only difference is
old now-unreferenced files which are still around in `%post` compared to
`%postun`.
While here, systemctl(1) is used in step 1 to stop the service when
relevant, instead of always relying on service(8).
Fixes#94.
There is no point in doing so because that script is executed by a
command. And hopefully that command cannot pollute the user's
environment.
If the user wants to enable autocompletion, he has to do that from his
shell configuration anyway. It is probably the case by default on many
Unix systems.
Fixesrabbitmq/rabbitmq-server-release#93.
`rabbitmq.conf` must be a very old way to specify environment variables because the installation moves it to `rabbitmq-env.conf` if found. This is a problem as the new sysctl-style config file is named `rabbitmq.conf`
Fixes#87
... and don't create entries for them if asked. For instance, don't try
to add an entry for 3.6.15-beta.2 even if the last one is 3.6.16.
In the RPM version of this script, this was already the case. However,
there was a tiny bug: even if we parsed the changelog and passed that to
grep(1), we instructed grep(1) to look directly at the spec anyway.
[#160270896]
We don't know yet if it is actually the case, but this is a safety for
the day Erlang 22.0 will be released, so that users are not in trouble
before we validated that RabbitMQ works with the new release.
[#160088605]
erlang-nox is a meta-package which pulls in most useful Erlang
applications for a developer. Unfortunately, it doesn't pin the version
of those packages. So for instance, erlang-nox 19.3 could pull in
erlang-base 21.0 without a warning.
This patch replaces this meta-package by all the "leaf" packages
RabbitMQ really depends on. By "really depends on", the list was reduced
compared to all the packages installed by erlang-nox, but it's still
conservative (i.e. it could probably be cleaned up further).
[#160232286]
The requirement is used to determine which version to pin. Before it had
to match exactly an available package version.
Now the script improved and it will use this requirement as a pattern
instead to figure out which package matches it. That's why the revision
must be dropped.
[#159273314]
https://www.rabbitmq.com/install-windows-manual.html#erlang-cookieFixes#81
packaging/windows: Look at Erlang 20.2+ cookie's location as well
While here, check if the cookie exists before copying it. This fixes an
uninformative error message in the installer output.
Use NSIS variable $SYSDIR
Adm should be group owner of everything in /var/log according to Debian/Ubuntu guidelines. Makes it possible for users in the adm group to read logs without sudo:ing.
Before this, this was working by chance because those dependencies were
brought by plugins. But if we build the package without any plugins, the
script complains about requires missing applications (kernel and
stdlib), and if we add hard-code them, it complains about other Erlang
applications not listed (sasl, mnesia, os_mon, ...).
See rabbitmq/rabbitmq-server#1359
This gives guidances for those users who wish to automatically restart RabbitMQ in the event of a failure. Tested by using the `Restart=on-failure` setting, then running `rabbitmqctl eval "erlang:halt(abort)."`
Ubuntu's Software Center reports a warning and Lintian reports the
following error:
E: rabbitmq-server: non-standard-toplevel-dir ets/
Reported by Giuliano Franchetto on #rabbitmq IRC channel.
On a fresh install, we want to limit access to the log directory to the
owner and group. This is in case sensitive data are logged.
We don't enforce the permissions on upgrade because:
1. We don't want to break exising installs by reducing
permissions.
2. The admin may want to setup different permissions.
References rabbitmq/rabbitmq-management#474.
[#150970897]
SLES 11 provides RPM 4.4 which fails to verify package signatures. It's
unclear what is the real cause, but all settings we tried were rejected
(v4/v3 signatures, MD5 or SHA1 digests).
So for now, disable package signing entirely for SLES 11.
[#150792874]
(cherry picked from commit c54728f51a)
Using GPG v3/v4 signatures wasn't the problem. My test was wrong: the
tested package was not signed. So even a GPG v3 signature is refused by
RPM.
In fact, it looks like RPM 4.4 has issues with package signature
verifications. Perhaps related to the SHA1 digest (but using an MD4
digest doesn't solve the problem). The cause is unclear.
Only RPM 4.4 is available on SLES 11. So for now, revert this change.
This reverts commit dc783c737a.
(cherry picked from commit 703081cdc0)
SLES 11 provides RPM 4.4 which fails to verify package signatures. It's
unclear what is the real cause, but all settings we tried were rejected
(v4/v3 signatures, MD5 or SHA1 digests).
So for now, disable package signing entirely for SLES 11.
[#150792874]
Using GPG v3/v4 signatures wasn't the problem. My test was wrong: the
tested package was not signed. So even a GPG v3 signature is refused by
RPM.
In fact, it looks like RPM 4.4 has issues with package signature
verifications. Perhaps related to the SHA1 digest (but using an MD4
digest doesn't solve the problem). The cause is unclear.
Only RPM 4.4 is available on SLES 11. So for now, revert this change.
This reverts commit dc783c737a.
It looks like RPM on SLES 11 fails to handle GPG v4 signatures, even
though it happily signed it:
# rpm -K -vvv ./rabbitmq-server-3.7.0~alpha.378-1.sles11.noarch.rpm
./rabbitmq-server-3.7.0~alpha.378-1.sles11.noarch.rpm:
Header V4 RSA/SHA1 signature: BAD, key ID 6026dfca
Header SHA1 digest: OK (895933d0ba5eca00759ebdfaa0d4e5d156ad0985)
V4 RSA/SHA1 signature: BAD, key ID 6026dfca
MD5 digest: OK (422c5b455a0f63055d5cd8701da8064b)
After forcing a GPG v3 signature, the signature check is successful:
# rpm -v -K ./rabbitmq-server-3.6.12.rc2+1.gf3f347e.dirty-1.sles11.noarch.rpm
./rabbitmq-server-3.6.12.rc2+1.gf3f347e.dirty-1.sles11.noarch.rpm:
Header SHA1 digest: OK (a9235a3ec1f7a893bd1fe2ec20c011542cfe88d4)
MD5 digest: OK (fd555d5b73180efcb8232f1f0a5a8a61)
[#150792874]
(cherry picked from commit 051f230096)
It looks like RPM on SLES 11 fails to handle GPG v4 signatures, even
though it happily signed it:
# rpm -K -vvv ./rabbitmq-server-3.7.0~alpha.378-1.sles11.noarch.rpm
./rabbitmq-server-3.7.0~alpha.378-1.sles11.noarch.rpm:
Header V4 RSA/SHA1 signature: BAD, key ID 6026dfca
Header SHA1 digest: OK (895933d0ba5eca00759ebdfaa0d4e5d156ad0985)
V4 RSA/SHA1 signature: BAD, key ID 6026dfca
MD5 digest: OK (422c5b455a0f63055d5cd8701da8064b)
After forcing a GPG v3 signature, the signature check is successful:
# rpm -v -K ./rabbitmq-server-3.6.12.rc2+1.gf3f347e.dirty-1.sles11.noarch.rpm
./rabbitmq-server-3.6.12.rc2+1.gf3f347e.dirty-1.sles11.noarch.rpm:
Header SHA1 digest: OK (a9235a3ec1f7a893bd1fe2ec20c011542cfe88d4)
MD5 digest: OK (fd555d5b73180efcb8232f1f0a5a8a61)
[#150792874]
This matches the distribution name and version we want to target (i.e.
SLES 11). In the future, we might want to also create an SLES 12
package.
Also, enable the new package in the default build. Before this, the
default target (`all`) would call `package-rpm-opensuse`. So
`package-rpm-suse` and `package-rpm-opensuse1012` were unused.
While here, the RPM-specific targets were reworked a bit. Here is the
dependency tree:
package
`-- package-rpm
|-- package-rpm-redhat
| |-- package-rpm-rhel6
| `-- package-rpm-rhel7
`-- package-rpm-suse
|-- package-rpm-opensuse
`-- package-rpm-sles11
For some reason, package-rpm-fedora isn't called at all. I don't know
why, this needs to be investigated.
This reverts part of commit 851561953a.
We need to hard-code the dependency on init-system-helpers to support
Ubuntu 14.04.
(cherry picked from commit 12d2edad42)
... 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)
... 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.
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)
Shortcuts for `rabbitmq-service.bat` should run as admin
because system control tools require admin.
Also make shortcuts run a command prompt and do not exit if there
is an error, so the error can be seen by an operator.
Part of rabbitmq/rabbitmq-server#1324
[#149953545]
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)
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.
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]
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]
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.
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]
Jean-Sébastien Pédron
Michael Klishin
Nicolas Bock
RabbitMQ CI
Robin Wallin
Michael Klishin
Spring Operator
Michael Klishin
Luke Bakken
Jean-Sébastien Pédron
Carl Hörberg
Daniil Fedotov
Luke Bakken
Diana Corbacho
cll
Michael Klishin
Tianon Gravi
Gabriele Santomaggio
Markos Chandras