🚨 Kafka Error Guide: 'Address already in use' — Free the Broker Port

Overview

When a Kafka broker (or KRaft controller) tries to bind its listener socket and the TCP port is already taken, startup fails immediately with a bind error and the process exits:

ERROR [KafkaServer id=1] Fatal error during KafkaServer startup. Prepare to shutdown (kafka.server.KafkaServer)
org.apache.kafka.common.KafkaException: Socket server failed to bind to 0.0.0.0:9092: Address already in use.
        at kafka.network.Acceptor.openServerSocket(SocketServer.scala:753)
        at kafka.network.Acceptor.<init>(SocketServer.scala:673)
Caused by: java.net.BindException: Address already in use

The KRaft controller listener produces the same failure on its own port:

java.net.BindException: Address already in use
        at sun.nio.ch.Net.bind0(Native Method)
        at kafka.network.Acceptor.openServerSocket(SocketServer.scala:753)

Symptoms

• Broker or controller exits during startup with java.net.BindException: Address already in use.
• The failure is immediate — it happens before the broker registers with the cluster.
• Restart loops under systemd: the unit keeps trying to start and failing on the same port.
• ss/netstat shows something already LISTENing on 9092 (or your controller/listener port).

Common Root Causes

• A previous broker JVM didn’t fully exit. A stale kafka.Kafka process still holds the port after a crash or a too-fast restart.
• Duplicate instance on the same host. Two units or two config files both bind the same port.
• Another service owns the port. An unrelated process (or a leftover container publishing 9092) grabbed it first.
• listeners and advertised.listeners misconfigured. Two listeners map to the same host:port, or a listener collides with the controller port.
• TIME_WAIT/socket lingering briefly holding the port right after a restart.
• Port reused across broker and controller in a combined KRaft node config.

Diagnostic Workflow

First identify exactly what is holding the port. Replace 9092 with the failing listener/controller port from the log:

sudo ss -ltnp | grep ':9092'
sudo lsof -iTCP:9092 -sTCP:LISTEN -n -P

Check for a lingering or duplicate Kafka process:

pgrep -af kafka.Kafka
ps -ef | grep -i '[k]afka' | grep -v zookeeper

Inspect the broker’s configured listeners so you know which ports it expects to bind:

grep -E '^(listeners|advertised.listeners|controller.quorum|process.roles)' \
  /etc/kafka/server.properties

Confirm what systemd is doing and read the startup failure:

systemctl status kafka --no-pager
journalctl -u kafka --since '10 min ago' | grep -i 'bind\|address already'

If the cluster is otherwise up, verify the broker is missing from the live set:

kafka-broker-api-versions.sh --bootstrap-server other-broker:9092 | head

Example Root Cause Analysis

A broker entered a systemd restart loop, each attempt ending in Socket server failed to bind to 0.0.0.0:9092: Address already in use. sudo ss -ltnp | grep ':9092' showed a process already LISTENing, and pgrep -af kafka.Kafka returned two PIDs — an old broker JVM from before a crash was still running and holding 9092, while systemd kept launching a new one that couldn’t bind.

The operator confirmed the old PID’s start time predated the incident, verified it was not serving traffic (it was defunct after the crash), and stopped it with a graceful kill (escalating to SIGKILL only after it refused to exit). Once the port was free, sudo ss -ltnp | grep ':9092' returned nothing and the systemd-managed broker started cleanly, bound its listener, and rejoined the cluster.

The root cause was a too-aggressive restart that launched a new broker before the previous JVM had released the socket. Setting an appropriate TimeoutStopSec and a small RestartSec in the unit prevented the race on subsequent restarts.

Prevention Best Practices

• Run one broker per host per port; keep a single authoritative server.properties and systemd unit.
• Give systemd a proper stop timeout (TimeoutStopSec) and a short RestartSec so the old JVM fully releases the socket before a restart.
• Keep listeners and advertised.listeners distinct and non-overlapping, and use separate ports for broker and controller listeners in KRaft.
• Reserve Kafka’s ports (9092, controller port) and avoid other services or containers publishing the same port on the host.
• Add a pre-start check that fails fast if the port is already bound, surfacing a clear message instead of a bind stack trace.
• After a crash, confirm no stale kafka.Kafka process remains before restarting.

Quick Command Reference

# What is holding the port
sudo ss -ltnp | grep ':9092'
sudo lsof -iTCP:9092 -sTCP:LISTEN -n -P

# Find stale/duplicate broker processes
pgrep -af kafka.Kafka

# Configured listeners
grep -E '^(listeners|advertised.listeners|controller.quorum)' /etc/kafka/server.properties

# Startup failure
journalctl -u kafka --since '10 min ago' | grep -i 'bind\|address already'

# Free the port (stop stale JVM), then restart
sudo systemctl restart kafka

Conclusion

Address already in use is a socket-bind failure, not a Kafka data problem: something already owns the listener or controller port when the broker starts. Diagnose it by finding the listening process with ss/lsof and checking for a stale or duplicate kafka.Kafka JVM, then free the port or fix the colliding listener configuration. Sensible systemd stop/restart timeouts and one-broker-per-port hygiene keep the failure from recurring on restart.