This guide covers RabbitMQ installation on RPM-based Linux (RedHat Enterprise Linux, CentOS, Fedora, openSUSE).
RabbitMQ is included in standard Fedora and RHEL repositories. However, the versions included are usually outdated and out of support.
There are two ways to install the most recent version of RabbitMQ on an RPM distribution:
The following guide focuses on RabbitMQ installation on RPM-based distributions such as Fedora, RHEL and CentOS. It covers a number of topics:
and more.
The package is distributed via Yum repositories on PackageCloud and Bintray.
rabbitmq-server is included in Fedora. However, the versions included often lag behind RabbitMQ releases. It is recommended that you use Yum repositories from PackageCloud or Bintray.
Check the Fedora package details for which version of the server is available for which versions of the distribution.
Below is a list of supported RPM-based distributions as of RabbitMQ 3.6.3:
The packages may work on other RPM-based distributions if dependencies are satisfied but their testing and support is done on a best effort basis.
RabbitMQ RPM package will require sudo privileges to install and manage. In environments where sudo isn't available, consider using the generic binary build.
Before installing RabbitMQ, you must install a supported version of Erlang/OTP. There are three commonly used sources for Erlang packages on RPM-based distributions.
Zero dependency Erlang RPM package for running RabbitMQ can be installed via Yum repositories on Package Cloud and Bintray as well as a direct download.
As the name suggests, the package strips off some Erlang modules and dependencies that are not essential for running RabbitMQ.
openSUSE package repositories provide Erlang so it can be installed using Zypper:
sudo zypper in erlang
Erlang versions available in the standard repositories will in practice be behind the most recent version. To use the last version with the newest features, add the openSUSE Factory repositories for Erlang:
# add the openSUSE erlang factory, obs:// extracts the http url for the matching distro. sudo zypper ar -f obs://devel:languages:erlang:Factory openSUSE-Erlang-Factory # import the signing key and refresh the repository sudo zypper --gpg-auto-import-keys refresh # install a recent Erlang version sudo zypper in erlang
Follow the instructions under "Installation using repository" at Erlang Solutions. Note that Erlang Solutions tend to provide cutting edge Erlang versions that may or may not be supported by RabbitMQ. Version locking (see below) is recommended when Erlang installed using this option.
Download and install the appropriate esl-erlang RPM from Erlang Solutions.
Follow the steps in the EPEL FAQ to enable EPEL on the target machine, then run the following command as root:
yum install erlang
yum version locking plugin is recommended to prevent unwanted Erlang upgrades. This is highly recommended when Erlang is installed via the Erlang Solutions repository.
When installing with Yum, all dependencies other than Erlang/OTP should be resolved and installed automatically as long as compatible versions are available. When that's not the case, dependency packages must be installed manually.
However, when installing a local RPM file via yum dependencies must be installed manually. The dependencies are:
A Yum repository with RabbitMQ packages is available from PackageCloud.
A quick way to install is to use a Package Cloud-provided script. Package Cloud also can be used to install a recent Erlang version via yum.
There are more installation options available:
See PackageCloud RabbitMQ repository instructions.
Package Cloud signs distributed packages using their own GPG keys. As of late 2018 Package Cloud is undergoing a signing key migration. Instead of relying on a "master key", projects will migrate to use repository-specific signing keys. Before the migration is completed, both old and new key must be imported for forward compatibility:
# import the new PackageCloud key that will be used starting December 1st, 2018 (GMT) rpm --import https://packagecloud.io/rabbitmq/rabbitmq-server/gpgkey # import the old PackageCloud key that will be discontinued on December 1st, 2018 (GMT) rpm --import https://packagecloud.io/gpg.key
After importing both keys please follow the Package Cloud repository setup instructions.
A Yum repository with RabbitMQ packages is available from Bintray. The package page provides a repository setup help section.
Bintray also can be used to install a recent Erlang version via yum.
Before the Yum repository can be used, RabbitMQ signing key must be imported first. This makes RPM tools trust the signature on the packages provided in the repository. To do so, run rpm --import as a superuser:
rpm --import https://github.com/rabbitmq/signing-keys/releases/download/2.0/rabbitmq-release-signing-key.asc
In order to use the Yum repository, a .repo file (e.g. rabbitmq.repo) has to be added under the /etc/yum.repos.d/ directory. The contents of the file will vary slightly between distributions (e.g. CentOS 7 and 8 vs. CentOS 6 vs. OpenSUSE).
The following example sets up a repository that will installRabbitMQ 3.8 and targets CentOS 8:
[bintray-rabbitmq-server] name=bintray-rabbitmq-rpm baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.8.x/el/8/ gpgcheck=0 repo_gpgcheck=0 enabled=1
On CentOS 7 the baseurl line would be slightly different:
[bintray-rabbitmq-server] name=bintray-rabbitmq-rpm baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.8.x/el/7/ gpgcheck=0 repo_gpgcheck=0 enabled=1
Same for CentOS 6:
[bintray-rabbitmq-server] name=bintray-rabbitmq-rpm baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.8.x/el/6/ gpgcheck=0 repo_gpgcheck=0 enabled=1
The following example targets OpenSUSE:
[bintray-rabbitmq-server] name=bintray-rabbitmq-rpm baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.8.x/opensuse/42.1/ gpgcheck=0 repo_gpgcheck=0 enabled=1
The following example targets SLES 11.x:
[bintray-rabbitmq-server] name=bintray-rabbitmq-rpm baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.8.x/sles/11 gpgcheck=0 repo_gpgcheck=0 enabled=1
The following example sets up a repository that will install RabbitMQ 3.7 on CentOS 7. Note that RabbitMQ 3.7 goes out of support in 2020.
[bintray-rabbitmq-server] name=bintray-rabbitmq-rpm baseurl=https://dl.bintray.com/rabbitmq/rpm/rabbitmq-server/v3.7.x/el/7/ gpgcheck=0 repo_gpgcheck=0 enabled=1
After downloading the server package, issue the following command as 'root':
rpm --import https://github.com/rabbitmq/signing-keys/releases/download/2.0/rabbitmq-release-signing-key.asc # This example assumes the CentOS 8 version of the package. # For CentOS 7, replace "el8" with "el7". yum install rabbitmq-server-3.8.14-1.el8.noarch.rpm
RabbitMQ public signing key can also be downloaded from rabbitmq.com:
rpm --import https://www.rabbitmq.com/rabbitmq-release-signing-key.asc # This example assumes the CentOS 8 version of the package. # For CentOS 7, replace "el8" with "el7". yum install rabbitmq-server-3.8.14-1.el8.noarch.rpm
In some cases it may easier to download the package and install it manually. The package can be downloaded from GitHub.
Description | Download | Signature |
---|---|---|
RPM for RHEL Linux 8.x, CentOS 8.x, Fedora 28+ (supports systemd) | rabbitmq-server-3.8.14-1.el8.noarch.rpm | Signature |
RPM for RHEL Linux 7.x, CentOS 7.x, Fedora 24+ (supports systemd) | rabbitmq-server-3.8.14-1.el7.noarch.rpm | Signature |
RPM for RHEL Linux 6.x, CentOS 6.x, Fedora prior to 19 | rabbitmq-server-3.8.14-1.el6.noarch.rpm | Signature |
RPM for openSUSE Linux | rabbitmq-server-3.8.14-1.suse.noarch.rpm | Signature |
RPM for SLES 11.x | rabbitmq-server-3.8.14-1.sles11.noarch.rpm | Signature |
The server is not started as a daemon by default when the RabbitMQ server package is installed. To start the daemon by default when the system boots, as an administrator run
chkconfig rabbitmq-server on
As an administrator, start and stop the server as usual:
/sbin/service rabbitmq-server start /sbin/service rabbitmq-server stop
On most systems, a node should be able to start and run with all defaults. Please refer to the Configuration guide to learn more and Production Checklist for guidelines beyond development environments.
Note: the node is set up to run as system user rabbitmq. If location of the node database or the logs is changed, the files and directories must be owned by this user.
RabbitMQ nodes bind to ports (open server TCP sockets) in order to accept client and CLI tool connections. Other processes and tools such as SELinux may prevent RabbitMQ from binding to a port. When that happens, the node will fail to start.
CLI tools, client libraries and RabbitMQ nodes also open connections (client TCP sockets). Firewalls can prevent nodes and CLI tools from communicating with each other. Make sure the following ports are accessible:
It is possible to configure RabbitMQ to use different ports and specific network interfaces.
The broker creates a user guest with password guest. Unconfigured clients will in general use these credentials. By default, these credentials can only be used when connecting to the broker as localhost so you will need to take action before connecting from any other machine.
See the documentation on access control for information on how to create more users and delete the guest user.
RabbitMQ installations running production workloads may need system limits and kernel parameters tuning in order to handle a decent number of concurrent connections and queues. The main setting that needs adjustment is the max number of open files, also known as ulimit -n. The default value on many operating systems is too low for a messaging broker (1024 on several Linux distributions). We recommend allowing for at least 65536 file descriptors for user rabbitmq in production environments. 4096 should be sufficient for many development workloads.
There are two limits in play: the maximum number of open files the OS kernel allows (fs.file-max) and the per-user limit (ulimit -n). The former must be higher than the latter.
On distributions that use systemd, the OS limits are controlled via a configuration file at /etc/systemd/system/rabbitmq-server.service.d/limits.conf. For example, to set the max open file handle limit (nofile) to 64000:
[Service] LimitNOFILE=64000
See systemd documentation to learn about the supported limits and other directives.
To configure kernel limits for Docker contains, use the "default-ulimits" key in Docker daemon configuration file. The file has to be installed on Docker hosts at /etc/docker/daemon.json:
{ "default-ulimits": { "nofile": { "Name": "nofile", "Hard": 64000, "Soft": 64000 } } }
The most straightforward way to adjust the per-user limit for RabbitMQ on distributions that do not use systemd is to edit the /etc/default/rabbitmq-server (provided by the RabbitMQ Debian package) or rabbitmq-env.conf to invoke ulimit before the service is started.
ulimit -S -n 4096
This soft limit cannot go higher than the hard limit (which defaults to 4096 in many distributions). The hard limit can be increased via /etc/security/limits.conf. This also requires enabling the pam_limits.so module and re-login or reboot. Note that limits cannot be changed for running OS processes.
For more information about controlling fs.file-max with sysctl, please refer to the excellent Riak guide on open file limit tuning.
RabbitMQ management UI displays the number of file descriptors available for it to use on the Overview tab.
rabbitmqctl status
includes the same value.
The following command
cat /proc/$RABBITMQ_BEAM_PROCESS_PID/limits
can be used to display effective limits of a running process. $RABBITMQ_BEAM_PROCESS_PID is the OS PID of the Erlang VM running RabbitMQ, as returned by rabbitmqctl status.
Configuration management tools (e.g. Chef, Puppet, BOSH) provide assistance with system limit tuning. Our developer tools guide lists relevant modules and projects.
To start and stop the server, use the service tool. The service name is rabbitmq-server:
# stop the local node sudo service rabbitmq-server stop # start it back sudo service rabbitmq-server start
service rabbitmq-server status will report service status as observed by systemd (or similar service manager):
# check on service status as observed by service manager sudo service rabbitmq-server status
It will produce output similar to this:
Redirecting to /bin/systemctl status rabbitmq-server.service ● rabbitmq-server.service - RabbitMQ broker Loaded: loaded (/usr/lib/systemd/system/rabbitmq-server.service; enabled; vendor preset: disabled) Drop-In: /etc/systemd/system/rabbitmq-server.service.d └─limits.conf Active: active (running) since Wed 2021-01-22 10:21:32 UTC; 25s ago Main PID: 957 (beam.smp) Status: "Initialized" CGroup: /system.slice/rabbitmq-server.service ├─ 957 /usr/lib/erlang/erts-10.2/bin/beam.smp -W w -A 64 -MBas ageffcbf -MHas ageffcbf -MBlmbcs 512 -MHlmbcs 512 -MMmcs 30 -P 1048576 -t 5000000 -stbt db -zdbbl 128000 -K true -- -root /usr/lib/erlang -progname erl -- -home /var/lib/rabbitmq -- ... ├─1411 /usr/lib/erlang/erts-10.2/bin/epmd -daemon ├─1605 erl_child_setup 400000 ├─2860 inet_gethost 4 └─2861 inet_gethost 4 Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: ## ## Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: ## ## RabbitMQ 3.8.11. Copyright (c) 2007-2021 VMware, Inc. or its affiliates. Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: ########## Licensed under the MPL 2.0. Website: https://www.rabbitmq.com/ Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: ###### ## Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: ########## Logs: /var/log/rabbitmq/rabbit@localhost.log Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: /var/log/rabbitmq/rabbit@localhost_upgrade.log Dec 26 10:21:30 localhost.localdomain rabbitmq-server[957]: Starting broker... Dec 26 10:21:32 localhost.localdomain rabbitmq-server[957]: systemd unit for activation check: "rabbitmq-server.service" Dec 26 10:21:32 localhost.localdomain systemd[1]: Started RabbitMQ broker. Dec 26 10:21:32 localhost.localdomain rabbitmq-server[957]: completed with 6 plugins.
rabbitmqctl, rabbitmq-diagnostics, and other CLI tools will be available in PATH and can be invoked by a sudo-enabled user:
# checks if the local node is running and CLI tools can successfully authenticate with it sudo rabbitmq-diagnostics ping # prints enabled components (applications), TCP listeners, memory usage breakdown, alarms # and so on sudo rabbitmq-diagnostics status # prints cluster membership information sudo rabbitmq-diagnostics cluster_status # prints effective node configuration sudo rabbitmq-diagnostics environment
All rabbitmqctl commands will report an error if no node is running. See the CLI tools and Monitoring guides to learn more.
Server logs can be found under the configurable directory, which usually defaults to /var/log/rabbitmq when RabbitMQ is installed via a Linux package manager.
RABBITMQ_LOG_BASE can be used to override log directory location.
Assuming a systemd-based distribution, system service logs can be inspected using
journalctl --system
which requires superuser privileges. Its output can be filtered to narrow it down to RabbitMQ-specific entries:
sudo journalctl --system | grep rabbitmq
The output will look similar to this:
Dec 26 11:03:04 localhost rabbitmq-server[968]: ## ## Dec 26 11:03:04 localhost rabbitmq-server[968]: ## ## RabbitMQ 3.8.11. Copyright (c) 2007-2021 VMware, Inc. or its affiliates. Dec 26 11:03:04 localhost rabbitmq-server[968]: ########## Licensed under the MPL 2.0. Website: https://www.rabbitmq.com/ Dec 26 11:03:04 localhost rabbitmq-server[968]: ###### ## Dec 26 11:03:04 localhost rabbitmq-server[968]: ########## Logs: /var/log/rabbitmq/rabbit@localhost.log Dec 26 11:03:04 localhost rabbitmq-server[968]: /var/log/rabbitmq/rabbit@localhost_upgrade.log Dec 26 11:03:04 localhost rabbitmq-server[968]: Starting broker... Dec 26 11:03:05 localhost rabbitmq-server[968]: systemd unit for activation check: "rabbitmq-server.service" Dec 26 11:03:06 localhost rabbitmq-server[968]: completed with 6 plugins.
The broker always appends to the log files, so a complete log history is retained.
logrotate is the recommended way of log file rotation and compression. By default, the package will set up logrotate to run weekly on files located in default /var/log/rabbitmq directory. Rotation configuration can be found in /etc/logrotate.d/rabbitmq-server.
If you have questions about the contents of this guide or any other topic related to RabbitMQ, don't hesitate to ask them on the RabbitMQ mailing list.
If you'd like to contribute an improvement to the site, its source is available on GitHub. Simply fork the repository and submit a pull request. Thank you!