node.js - servers - Nodo/Express: EADDRINUSE, Dirección ya en uso-Detener servidor

stop all node apps

Question

Tengo un servidor simple corriendo en node.js usando connect:

var server = require(''connect'').createServer();
//actions...
server.listen(3000);

En mi código tengo manejadores reales, pero esa es la idea básica. El problema que sigo teniendo es

EADDRINUSE, Address already in use

Recibo este error cuando ejecuto mi aplicación nuevamente después de que se bloqueó previamente o errores. Como no estoy abriendo una nueva instancia de terminal, cierro el proceso con ctr + z .

Estoy bastante seguro de que todo lo que tengo que hacer es cerrar el servidor o la conexión. Intenté llamar a server.close() en process.on(''exit'', ...); sin suerte

Answer 1

¿Estás en linux o windows? Si está en Linux, escriba: ps y verifique el PID de su proceso de nodo.

entonces, sudo kill PID

EDITAR : Para Windows:

Utilice la lista de tareas para mostrar la lista de procesos en ejecución:

tasklist /O

y luego elimine el proceso del nodo como tal (PID obtenido del comando tasklist ):

taskkill /pid PID

Answer 2

Administrador de tareas (ctrl + alt + del) ->

Pestaña Procesos ->

seleccione el proceso "node.exe" y presione "Terminar proceso"

Answer 3

Aquí hay un liner (reemplace 3000 con un puerto o una variable de configuración):

kill $(lsof -t -i:3000)

Answer 4

Con el debido respeto a todas las respuestas en el formulario, me gustaría agregar un punto.

Encontré que cuando finalizo una aplicación de nodo por error usando Ctrl + Z, la próxima vez que intente abrirla obtuve el mismo error EADDRINUSE.

Cuando uso Ctrl + C para terminar una aplicación de nodo, la próxima vez que la abrí, lo hice sin ningún problema.

Cambiar el número de puerto a otro que no sea el error resolvió el problema.

Answer 5

El nodo se está ejecutando en algún lugar de la memoria y tiene ese puerto bloqueado. En Windows, este problema ocurrirá, como la mayoría de los problemas de Windows, se resolverá presionando CTRL + ALT + DEL y / o reiniciando.

Answer 6

En linux

Añadir función a ~/.bashrc :

function killTcpListen () {
  kill -9 $(lsof -sTCP:LISTEN -i:$1 -t)
}

Tirar cambios: source ~/.bashrc

Y killTcpListen 3000 : killTcpListen 3000

Answer 7

Encontré esta solución, pruébala.

  pkill node

Answer 8

Encontré para mí que la forma más rápida de resolver esto era:

killall node

Answer 9

Este comando enumera las tareas relacionadas con el ''nodo'' y termina cada una de ellas.

kill -9  $( ps -ae | grep ''node'' | awk ''{print $1}'')

Answer 10

Esto significa que tiene dos servidores de nodo que se ejecutan en el mismo puerto, si uno está ejecutando en el puerto, digamos que 3000 cambiará el otro a otro puerto, digamos 3001 y todo funcionará bien

Answer 11

Golpeé esto en mi laptop corriendo win8. esto funciono

Ejecute cmd.exe como ''Administrador'':

C:/Windows/System32>taskkill /F /IM node.exe
SUCCESS: The process "node.exe" with PID 11008 has been terminated.

Answer 12

Las razones de estos problemas son:

1. Cualquier aplicación puede estar ejecutándose en este puerto como Skype.
2. Es posible que el nodo se haya bloqueado y que el puerto no se haya liberado.
3. Es posible que haya intentado iniciar el servidor más de uno. Para resolver este problema, uno puede mantener un valor booleano para verificar si el servidor se ha iniciado o no. Se debe iniciar solo si el valor booleano devuelve false o no definido;

Answer 13

Me pregunto, ¿por qué nadie mencionó aún esta posibilidad?

• Si proporciona ::listen(port) string ::listen(port) con una cadena (intencionalmente o no), que no sería una representación válida del número de puerto, entonces se puede convertir internamente al número de puerto -1 , y luego el motor intentará conectarse a eso -1 puerto, que luego produce el mismo error EADDRINUSE , que a su vez puede ser un poco confuso y te hace girar en la dirección equivocada para la búsqueda de corrección de errores ( hi, me xD ).

Entonces, depure su código y verifique qué pasa exactamente a las funciones, antes de comenzar a verificar los procesos que están usando su puerto .

Answer 14

Para su información, puede detener el proceso en un comando sudo fuser -k 3000/tcp . Esto se puede hacer para todos los demás puertos como 8000, 8080 o 9000 que se usan comúnmente para el desarrollo.

Answer 15

Para todos los que vinieron a este post y probaron, probablemente todos usen nodemon o siempre lo hagan. Por ejemplo, si ejecuta PORT=6060 Nodemon , podría obtener el mismo error que el puerto 6060 ya está en uso.

Si este es el caso, simplemente ejecute su proyecto sin nodemon si realmente necesita definir el puerto durante la ejecución. Alternativamente, puedes definir el puerto en tu propio archivo si quieres mantenerte en nodemon.

Para mi hago esto ahora PORT=6060 node app.js

Answer 16

Por si acaso, compruebe si ha añadido esta línea varias veces por error.

app.listen(3000, function() {
  console.log(''listening on 3000'')
});

El código anterior es para Express, pero solo verifique si está intentando usar el mismo puerto dos veces en su código.

Answer 17

Primero, querrá saber qué proceso está usando el port 3000

sudo lsof -i :3000

Esto mostrará una lista de todos los PID que escuchan en este puerto. Una vez que tenga el PID , puede terminar con lo siguiente:

kill -9 {PID}

Answer 18

Puede usar hot-node para evitar que su servidor se bloquee / errores en tiempo de ejecución. Hot-node reinicia automáticamente la aplicación nodejs por usted siempre que haya un cambio en el programa de nodo [fuente] / proceso [programa de nodo en ejecución].

Instale hot-node usando npm usando la opción global:

npm install -g hotnode

Answer 19

Recibí este error una vez y tomé muchos de los enfoques aquí.

Mis problemas eran que tenía dos app.listen(3000); llamadas en el mismo script app.js. La primera app.listen () tuvo éxito donde la segunda lanzó el error.

Otro comando útil que encontré que me ayudó a depurar fue sudo fuser -k 3000/tcp que eliminará cualquier proceso falso que pueda haber iniciado (algunos procesos pueden reiniciarse, por ejemplo, si se ejecuta con forever.js, pero fue útil para mí).

Answer 20

Si usa Mac o Linux, puede probar este comando en la terminal.

 killall node

Answer 21

También puede ir a la ruta de la línea de comandos:

ps aux | grep node

para obtener los identificadores de proceso.

Entonces:

kill -9 PID

Hacer el -9 en kill envía un SIGKILL (en lugar de un SIGTERM). SIGTERM ha sido ignorado por el nodo para mí a veces.

Answer 22

Tenga cuidado de que, como yo, no tenga otra caja de DOS (o similar) en ejecución que haya olvidado de x)

¡Produció el error exacto mostrado arriba!

Answer 23

Usted puede utilizar más de un servidor. Puede cerrarlos y usar un servidor. En Linux puede usar el comando de nodo killall.

Answer 24

Usuarios de PowerShell:

Taskkill / IM node.exe / F

Answer 25

Verifique el ID de PID, es decir, el proceso que se ejecuta en el puerto 3000 con el siguiente comando:

lsof -i tcp:3000

Saldría algo como lo siguiente:

COMMAND  PID   USER   FD   TYPE  DEVICE  SIZE/OFF NODE NAME
node     5805  xyz    12u  IPv6  63135    0t0     TCP  *:3000 (LISTEN)

Ahora mata el proceso usando:

kill -9 5805

Answer 26

Win10, git bash v2.15, nodo v8.9.1, npm v5.5.1

Tuve un script package.json para iniciar node: "start": "node index.js"

Siempre que utilicé esto, independientemente de si lo maté con ctrl + c, me encontré con este problema.

Si simplemente ejecuté node index.js desde git bash en lugar de npm run start y maté con ctrl + c, nunca obtuve este error.

No estoy seguro de por qué, pero pensé que esto podría ayudar a alguien.

Answer 27

Yo también tengo el mismo problema.

• cerrar todas las indicaciones de cmd o git bash en el administrador de tareas

si eso no funcionó reinicie su sistema

En otro escenario, tuve que instalar el último nodo y le di a npm install como administrador funcionó.

Answer 28

process.on(''exit'', ..) no se llama si el proceso se bloquea o se detiene. Solo se invoca cuando finaliza el bucle de eventos, y dado que server.close() de alguna manera finaliza el bucle de eventos (todavía tiene que esperar las pilas actualmente en ejecución aquí y allá) no tiene sentido poner eso dentro del evento de salida ... .

En caso de fallo, realice process.on(''uncaughtException'', ..) y en kill haga process.on(''SIGTERM'', ..)

Dicho esto, SIGTERM (señal de interrupción predeterminada) permite que la aplicación se limpie, mientras que SIGKILL (terminación inmediata) no permite que la aplicación haga nada.