🚨 Redis Error Guide: 'bind: Address already in use' — Free Port 6379 and Fix Duplicate Redis Startups

Overview

Redis fails to start with this error when it tries to open its listening socket on a port (default 6379) or a Unix socket path that another process is already bound to. The kernel returns EADDRINUSE, Redis logs the failure, and the process exits before it can accept clients.

The literal error in the log / on the console:

Warning: Could not create server TCP listening socket *:6379: bind: Address already in use
Failed listening on port 6379 (tcp), aborting.

This is a startup problem, not a data problem: something already owns the address Redis wants. Almost always it is a second redis-server (a manual start on top of the systemd unit, an orphaned process from a failed restart, or two config files pointing at the same port) — or a stale Unix socket file left behind after an unclean shutdown.

Symptoms

• systemctl start redis or redis-server redis.conf exits immediately; the unit shows failed.
• The log ends with Could not create server TCP listening socket and aborting.
• A redis-cli PING connects — to the old process — even though your new start failed.

sudo systemctl start redis-server
sudo systemctl status redis-server

● redis-server.service - Advanced key-value store
   Active: failed (Result: exit-code)
   ... Failed listening on port 6379 (tcp), aborting.

Common Root Causes

1. A redis-server is already running on that port

The most common case: the service is already up, and a second start (manual or a duplicate unit) collides.

sudo ss -ltnp | grep :6379

LISTEN 0 511 0.0.0.0:6379 0.0.0.0:* users:(("redis-server",pid=812,fd=6))

2. An orphaned process from a failed restart

A previous redis-server didn’t exit (or was left detached), still holding the port while the service manager tries to start a new one.

3. Two config files, same port

Two redis.conf (or a systemd template instance) both specify port 6379, so the second to start collides.

4. Stale Unix socket file

unixsocket /var/run/redis/redis.sock was left on disk after an unclean shutdown, so binding it fails.

5. Another service occupying the port

A non-Redis process (a misconfigured proxy, a container publishing 6379) already holds the port.

Diagnostic Workflow

Step 1: Find what owns the port

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

The pid/process name tells you whether it’s Redis or something else.

Step 2: Check for running redis-server processes

ps -ef | grep '[r]edis-server'
sudo systemctl status 'redis*'

Look for more instances than you expect (e.g. a manual start plus the unit).

Step 3: Confirm the port in each config

grep -REn '^port|^unixsocket|^bind' /etc/redis/

Two files with the same port is a config bug.

Step 4: Check for a stale socket file

ls -l /var/run/redis/redis.sock 2>/dev/null

If the file exists but no process owns it, it’s stale.

Step 5: Read the startup log

sudo journalctl -u redis-server --no-pager | grep -iE 'bind|Address already in use|aborting' | tail

Example Root Cause Analysis

After a deploy, systemctl restart redis-server reports success but the app can’t reach the expected new instance, and the journal shows repeated Could not create server TCP listening socket *:6379: bind: Address already in use. redis-cli PING still returns PONG — from an old process.

ss reveals the culprit: a redis-server started manually during an earlier debugging session is still bound to 6379, so systemd’s managed instance can never take the port:

sudo ss -ltnp | grep :6379

LISTEN 0 511 0.0.0.0:6379 users:(("redis-server",pid=812,fd=6))

ps -o pid,ppid,cmd -p 812

  PID  PPID CMD
  812     1 redis-server *:6379   # detached, not under systemd

The orphaned PID 812 was reparented to init and never stopped. The fix was to stop the managed unit, terminate the orphan cleanly, then start the unit so only systemd owns the port:

sudo systemctl stop redis-server
sudo kill 812                       # graceful; SIGTERM lets Redis save if configured
sleep 1; sudo ss -ltnp | grep :6379 || echo "port free"
sudo systemctl start redis-server
redis-cli PING                      # PONG from the managed instance

To prevent recurrence, the team removed the manual-start step from their runbook and relied only on the systemd unit, so two redis-server processes can no longer fight over 6379.

Prevention Best Practices

• Manage Redis through a single mechanism (the systemd unit) — never redis-server manually on top of a managed service.
• Give each instance on a host a distinct port (and unixsocket path); use systemd template units (redis@.service) for multiple instances.
• On unclean shutdowns, ensure the old process is gone (ss/ps) before starting a new one; add a short pre-start check if restarts are automated.
• Configure unixsocket cleanup or verify the socket path is free on start.
• Alert if more than one redis-server process is running per intended instance.
• Feed startup failures into the free incident assistant, and browse more Redis guides.

Quick Command Reference

# What owns the port?
sudo ss -ltnp | grep :6379
sudo lsof -iTCP:6379 -sTCP:LISTEN -P -n

# Running redis processes and services
ps -ef | grep '[r]edis-server'
sudo systemctl status 'redis*'

# Config port/socket audit
grep -REn '^port|^unixsocket|^bind' /etc/redis/

# Stale socket file
ls -l /var/run/redis/redis.sock

# Free the port cleanly, then restart the managed unit
sudo systemctl stop redis-server
sudo kill <pid>
sudo systemctl start redis-server

Conclusion

bind: Address already in use means Redis can’t open its listening address because something else already holds it. The typical root causes are:

1. A redis-server already running on that port (often a manual start on top of the service).
2. An orphaned process from a failed restart still holding the port.
3. Two config files pointing at the same port.
4. A stale Unix socket file after an unclean shutdown.
5. A non-Redis process occupying the port.

Find the owner with ss/lsof, stop the duplicate or orphan cleanly, and standardize on a single management mechanism with distinct ports per instance so two processes can never contend for the same address again.