🚨 RabbitMQ Error Guide: 'Failed to start Ranch listener ... eaddrinuse' — Fix Port Already in Use

Overview

When RabbitMQ starts, it opens several TCP listeners — AMQP on 5672 (or 5671 for TLS), the management plugin on 15672, inter-node distribution on 25672, and the Erlang Port Mapper Daemon (epmd) on 4369. If any of those ports is already held by another process, the listener fails to bind and the node aborts startup with an eaddrinuse error:

BOOT FAILED
===========
Error during startup: {error,
  {rabbitmq_management,
    {{shutdown,
       {failed_to_start_child,rabbit_web_dispatch_registry,
         {could_not_start_listener,[{port,15672}],eaddrinuse}}},
     ...}}}

The AMQP listener variant, raised by the underlying Ranch acceptor, reads:

Failed to start Ranch listener rabbit_amqp_listener in
:ranch_tcp:listen([{port,5672}]) for reason :eaddrinuse
(address already in use)

eaddrinuse is the operating system’s EADDRINUSE: the requested address and port pair is already bound by something else, so the kernel refuses the second bind.

Symptoms

• The service fails to come up; systemctl status rabbitmq-server shows a failed/activating state and the boot log ends in eaddrinuse.
• rabbitmq-diagnostics status reports the node is not running or unreachable.
• The failure names a specific port (5672, 5671, 15672, 25672, or 4369), which tells you exactly which listener couldn’t bind.
• On a restart loop, the node repeatedly tries to start and dies within seconds, because the conflicting process never releases the port.
• Sometimes only the management plugin fails (port 15672) while the core broker would otherwise start — the boot still aborts because a configured plugin listener couldn’t bind.

Common Root Causes

• A previous RabbitMQ instance is still running. An old beam.smp process from an unclean shutdown or a manual rabbitmq-server invocation still holds 5672/25672 while systemd tries to start a new one.
• A stale epmd is bound to 4369. epmd outlives the broker; a leftover or mismatched epmd on 4369 can block distribution startup.
• Another application owns the port. Something unrelated (a proxy, a different broker, a dev container, or another AMQP service) is already listening on 5672 or 15672.
• Two RabbitMQ nodes configured with the same ports on one host. Running multiple nodes without distinct RABBITMQ_NODE_PORT/RABBITMQ_DIST_PORT values collides them.
• A container port mapping conflict. Two containers publish to the same host port, or a host process already uses the port the container maps to.
• TIME_WAIT / lingering sockets after a crash briefly hold the port, causing an eaddrinuse on an immediate restart until the socket is reaped.

Diagnostic Workflow

Start by reading the exact port from the boot log — it’s the single most useful piece of information:

sudo journalctl -u rabbitmq-server --since '10 min ago' | grep -i "eaddrinuse\|ranch\|could_not_start_listener"

Identify what is holding that port. Use whichever tool is available:

# What process owns 5672 (repeat for 15672, 25672, 4369)?
sudo ss -ltnp 'sport = :5672'
sudo lsof -iTCP:5672 -sTCP:LISTEN

Check specifically for a lingering RabbitMQ/Erlang process from a previous run:

ps -ef | grep -E 'beam.smp|epmd|rabbitmq' | grep -v grep

Inspect epmd and which nodes it has registered on 4369:

epmd -names

epmd: up and running on port 4369 with data:
name rabbit at port 25672

Confirm whether systemd thinks the service is already active (so a manual start is colliding with the managed one):

systemctl status rabbitmq-server --no-pager

If ss/lsof shows the port owned by an existing beam.smp whose PID matches a running RabbitMQ, the “conflict” is simply a second start attempt against an already-running node. If it’s owned by an unrelated program, you have a genuine port clash to resolve.

Example Root Cause Analysis

After a host was force-rebooted mid-shutdown, the rabbitmq-server service entered a restart loop, each attempt ending in Failed to start Ranch listener rabbit_amqp_listener ... :eaddrinuse on port 5672. The operator’s first assumption was another application squatting on 5672.

sudo ss -ltnp 'sport = :5672' showed the port was held by a beam.smp process — but its PID did not match the one systemd was trying to start. ps -ef | grep beam.smp confirmed a leftover Erlang VM from the pre-reboot RabbitMQ that had never been reaped; its supervising unit was gone, but the process (and its bound sockets) survived. Meanwhile epmd -names still listed the old rabbit node on 25672, corroborating that the previous instance was effectively still alive.

The conflict wasn’t an external application at all — it was RabbitMQ colliding with its own orphaned process. The operator stopped the managed unit, terminated the stale beam.smp and its epmd, confirmed the ports were free with ss -ltnp, then started the service cleanly and it bound all listeners on the first attempt. The takeaway: before blaming another service, verify whether the process holding the port is a leftover instance of RabbitMQ itself.

Prevention Best Practices

• Always stop the broker cleanly with rabbitmqctl stop or systemctl stop rabbitmq-server so listeners release their ports before a restart.
• Manage RabbitMQ exclusively through systemd, not ad-hoc rabbitmq-server & invocations, so you never end up with two instances competing for the same ports.
• Give co-located nodes distinct ports. When running multiple nodes on one host, set unique RABBITMQ_NODENAME, RABBITMQ_NODE_PORT, and RABBITMQ_DIST_PORT per node.
• Reserve RabbitMQ’s ports. Document and avoid assigning 5672/5671/15672/25672/4369 to other services on the same host.
• In containers, avoid duplicate host mappings. Ensure no two containers publish the same host port and that the host isn’t already using it.
• Add a startup pre-check in automation that runs ss -ltnp for the required ports before starting, so a conflict is caught with a clear message instead of a cryptic boot failure.

Quick Command Reference

# Which port failed to bind?
sudo journalctl -u rabbitmq-server | grep -i "eaddrinuse"

# What owns the port (repeat for 15672, 25672, 4369)?
sudo ss -ltnp 'sport = :5672'
sudo lsof -iTCP:5672 -sTCP:LISTEN

# Is a stale RabbitMQ/Erlang process still alive?
ps -ef | grep -E 'beam.smp|epmd' | grep -v grep

# What has epmd registered on 4369?
epmd -names

# Clean restart through systemd
sudo systemctl stop rabbitmq-server
# (verify ports are free with ss -ltnp before starting)
sudo systemctl start rabbitmq-server

Conclusion

An eaddrinuse failure at RabbitMQ startup is a binding conflict, and the boot log hands you the one fact that matters: which port couldn’t be claimed. From there the workflow is mechanical — use ss or lsof to see what owns that port, and decide whether it’s an unrelated application, a duplicate configuration, or, most often, an orphaned beam.smp/epmd from the broker’s own previous life that never released its sockets.

The durable fix is operational hygiene: stop the broker cleanly, manage it solely through systemd so you never race two instances, and give any co-located nodes distinct ports. A simple pre-start port check in your automation turns this cryptic boot abort into an early, readable warning. For more startup and clustering fixes, see the RabbitMQ guides.