For anyone running Streetmix in a dev environment (observed in Mac OSX), sometimes a Node server does not shut down cleanly, which means the next time you run npm start to restart the server, Node continually crashes with an error message that includes the large error code EADDRINUSE: 8000 (something like this). This issue documents a workaround and creates a call-to-action to invite an investigation and possible long term solution into the problem.
If you are currently trapped in the EADDRINUSE error loop, force the current process to end with Control-C.
Run npm stop to make sure any child processes are killed.
Next, we need to find the previous zombie process. We know it's still running on port 8000. Run:
lsof -i :8000
Sometimes you will see a long list of processes including Google Chrome and node. You want the PID of the node process. It can be any number.
Run this command, where x is the PID number:
This should remove the zombie process. The next time you run npm start, things should be working as normal.
It is not entirely clear why this occurs. It does not appear to be the result of failing to close the process when asked, but sometimes the process simply "hangs" and drops you back onto a terminal prompt, although the process continues to run in the background. This can happen when the dev server has been running for a long period of time.
For people working long-term on Streetmix this occurs frequently enough to be a common problem.
Is this a Node problem?
Is this an Express server problem?
Is this an effect of how we watch (supervise) the process? Is this related to spawning a child process for MongoDB?
Does this occur on any other OS? (e.g. Windows, Linux)
The text was updated successfully, but these errors were encountered:
Yes, it is the server causing the problem but it is not due to the express framework
Yes it does
EADDRINUSE is thrown when another process is utilizing the port you're trying to connect to. In this case it is due to the node process continuing to run in the background.
I don't know of a solution to this except manually killing the process.
To stop this I'd recommend using kill -s 15 <PID>
instead of kill <PID>
The difference being that kill by default sends SIGKILL (9) signal, whose behavior is to kill the process immediately. SIGTERM (15) also kill the process but allows it a chance to end gracefully (i.e. giving the process a chance to clean up)