Rails dice que ya hay un servidor corriendo: el archivo pid, y el puerto

Rails te da dos fallas distintas que se ven igual, “el servidor no parte”, y necesitan arreglos opuestos. Leer bien el mensaje es la mayor parte del trabajo.

Falla uno: el archivo pid

A server is already running. Check /tu/app/tmp/pids/server.pid.

Este mensaje no es sobre el puerto. Rails escribe su ID de proceso en tmp/pids/server.pid cuando arranca y borra el archivo cuando se detiene. Si el proceso muere sin limpiar, un crash, un kill -9, una terminal cerrada, el archivo sobrevive con un ID de proceso que ya no existe.

Rails ve el archivo, asume que hay un servidor corriendo, y se niega antes de siquiera tocar el puerto 3000.

Revisa si el proceso está vivo de verdad:

cat tmp/pids/server.pid
ps -p $(cat tmp/pids/server.pid)

Si ps no imprime nada más que el encabezado, el ID está obsoleto y el archivo está mintiendo. Bórralo:

rm tmp/pids/server.pid

Y arranca normal. Si ps sí muestra un proceso Rails vivo, entonces está corriendo de verdad y lo que quieres es la sección siguiente.

Falla dos: el puerto sí está tomado

Address already in use - bind(2) for "127.0.0.1" port 3000 (Errno::EADDRINUSE)

Ese es el conflicto de puerto real, y el archivo pid no tiene nada que ver. Algo más ocupa el 3000: otra app de Rails, un servidor de Node, un contenedor de Docker publicando el 3000.

Encuéntralo:

lsof -i :3000

Y libéralo:

lsof -ti :3000 | xargs kill

Si el proceso es un docker-proxy, no lo mates. Detén el contenedor, porque si no Docker simplemente lo vuelve a poner.

Por qué en Rails aparece tanto el caso del pid

Dos costumbres lo vuelven común.

Ctrl+C es la salida limpia, cerrar la terminal no. Ctrl+C le permite a Rails borrar el archivo pid. Cerrar la ventana, o salir de la app de terminal con el servidor en primer plano, muchas veces no.

kill -9 se salta la limpieza por definición. SIGKILL no se puede capturar, así que el proceso no tiene ninguna oportunidad de borrar nada. Si tienes la costumbre de tirar -9, vas a tener la costumbre de dejar archivos pid obsoletos. Usa un kill normal primero y déjalo salir bien.

Puma, y varios workers

Si corres Puma en modo cluster, el puerto lo ocupan varios procesos a la vez, el padre y sus workers. Matar un worker no libera nada, porque los demás siguen ocupando el puerto.

Por eso importa la forma con xargs:

lsof -ti :3000 | xargs kill

-t imprime todos los IDs de proceso del puerto y xargs se los pasa a un solo kill, así se va el cluster completo.

Correr en otro puerto

A veces solo quieres seguir trabajando:

rails server -p 3001

Vale la pena dejarlo fijo si habitualmente tienes dos apps de Rails abiertas. Dos proyectos compartiendo el default del framework es un conflicto que te agendaste tú mismo.

Un orden rápido

1. Lee el mensaje. ¿Archivo pid, o EADDRINUSE?
2. Archivo pid: revisa con ps, borra el archivo si el proceso ya no está.
3. EADDRINUSE: lsof -i :3000, y después mátalo, o detén el contenedor si es Docker.
4. Con apuro: -p 3001.

Más sobre el error de fondo en qué significa realmente EADDRINUSE.

Bosun muestra qué está ocupando el puerto 3000 en tu barra de menú, con los contenedores de Docker nombrados en vez de aparecer como docker-proxy, y colapsa un cluster de Puma en una sola fila. macOS 14 o posterior, prueba de 14 días.