Puerto 6379 de Redis ocupado: revisa si acaso necesitas levantar uno

Could not create server TCP listening socket *:6379: bind: Address already in use

redis-server imprime eso y se sale. Antes de salir a cazar un proceso para matar, hay una pregunta que vale la pena hacerse y que la gente se salta.

¿Ya hay un Redis funcionando?

Muchas veces el conflicto no es un problema. Un Redis que levantaste la semana pasada, o uno que Homebrew arranca al iniciar sesión, está ahí funcionando perfecto. No necesitas un segundo, necesitas usar el que tienes.

redis-cli ping

Si eso responde PONG, Redis está arriba y sano, y tu app se puede conectar ahora mismo. No hay nada que arreglar. Cierra la terminal y sigue.

Esto es lo más útil de toda esta página, y sorprende lo seguido que la respuesta es “ya tienes uno”.

Si sí necesitas detenerlo, encuentra al dueño

lsof -i :6379

Como con cualquier base de datos, el dueño importa más que el PID, porque los gestores reinician lo que matas.

Homebrew:

brew services list
brew services stop redis

Homebrew registra un trabajo de launchd. Mata el proceso directo y launchd lo levanta de nuevo en segundos, lo que se ve exactamente igual a que el kill no hubiera hecho nada.

Docker:

docker ps --filter "publish=6379"
docker stop <contenedor>

Matar docker-proxy no tiene sentido, Docker vuelve a publicar el puerto de inmediato.

Levantado a mano: ahí sí corresponde terminarlo normalmente.

redis-cli shutdown

Eso es más limpio que un kill, porque Redis guarda su conjunto de datos al salir si tiene persistencia configurada. Úsalo en vez de señales cuando puedas.

Dos instancias de Redis a propósito

Correr instancias separadas por proyecto es razonable, y fácil, porque Redis toma el puerto como argumento:

redis-server --port 6380

Y apuntas ese proyecto al 6380. Mejor que detener y levantar una instancia compartida cada vez que cambias de proyecto, y mantiene separado el espacio de claves de cada uno, lo que evita toda una categoría de bugs confusos.

Si prefieres una sola instancia, Redis tiene bases numeradas, SELECT 1, SELECT 2 y así, aunque en la práctica instancias separadas son más claras.

El caso donde nada escucha

lsof -i :6379 no imprime nada y Redis igual se niega a ocupar el puerto. Eso es TIME_WAIT, un estado de TCP que retiene un puerto recién cerrado por unos treinta segundos. Ningún proceso lo posee, así que no hay nada que matar y esperar es el arreglo.

El detalle en qué significa realmente EADDRINUSE.

Una nota sobre exponer Redis

Por defecto Redis se ata a localhost, que es lo que quieres en una máquina de desarrollo. Si lo cambias a 0.0.0.0 para alcanzarlo desde un contenedor u otro dispositivo, expusiste una base de datos sin contraseña a todo lo que esté en tu red.

El modo protegido de Redis bloquea lo peor de eso por defecto, pero la costumbre segura en un notebook que se conecta a redes ajenas es dejar la dirección de bind tal como está salvo que tengas una razón concreta, y poner contraseña si igual necesitas abrirlo.

Más sobre esa distinción en qué es realmente localhost.

Bosun muestra qué hay en el 6379 en tu barra de menú, y si el Redis que lo ocupa es un contenedor, un servicio de brew o algo que levantaste tú. macOS 14 o posterior, prueba de 14 días.