nestjs
getting `EADDRINUSE` error when using start with watch mode with an async `beforeApplicationShutdown`
Is there an existing issue for this?
- [X] I have searched the existing issues
Current behavior
when we have an async beforeApplicationShutdown that takes too long to resolve, nest start --watch doesn't kill all the processes properly after file changes, which leads to an EADDRINUSE: address already in use error
https://user-images.githubusercontent.com/13461315/163654949-53f18d03-fc89-4757-88fe-e1f7d99a8cd1.mp4
Minimum reproduction code
https://gitlab.com/micalevisk/nestjs-cli-issue-1614
Steps to reproduce
git clone https://gitlab.com/micalevisk/nestjs-cli-issue-1614
cd nestjs-cli-issue-1614
-
npm ci -
npm run start:dev - change any source file
- see the error
Expected behavior
nestjs CLI should kill all processes before restarting the app
Package version
8.2.x
9.2.x - using forceCloseConnections: true doesn't fixes this
10.0.3
NestJS version
8.4.x 9.3.x 10.0.3
Node.js version
16.14.2
In which operating systems have you tested?
- [ ] macOS
- [ ] Windows
- [X] Linux
I guess this is beyond nest start --watch. See here that the app exits right away when we press ctrl+c when starting the app with nest start (it works if we use node) instead of waiting for beforeApplicationShutdown hook:
https://user-images.githubusercontent.com/13461315/164307593-36add876-339a-4498-b412-e34cfcd0604f.mp4
And this is related with #1487 So I believe that if we manage to fix that one, we'll fix this issue accordingly.
I am not sure, but looks like it is related to how nest starts typescript, it just not wait process stop at all, even if you start npm run start you will see same behaviour
It may not be directly related but I was experiencing this issue (EADDRINUSE error when using start with watch mode) constantly while running nest in a container (nest start --watch). However it didn't seem to occur while running the project locally (no container).
Changing the port I was using didn't help but what did seem to help was changing the way I was setting up my WORKDIR and COPY commands.
Changing from something like this (which based on the image I'm using set the user to someuser):
WORKDIR /usr/src/app
COPY --chown=someuser:someuser package*.json ./
...
COPY --chown=someuser:someuser . .
to something like this:
USER root
WORKDIR /usr/src/app
COPY package*.json ./
...
COPY . .
Before making this change, my watch command failed after every single file change (which caused me to have to compose up again every time); and after making this change it has not failed at all so far.
I was facing the same issue.
In my case, it was caused by the shutdown hook suggested here.
Once I removed the code, the problem was gone.
By reading the docs, I've found that I need to update the bootstrap file.
Now the problem is gone.
That won't solve the issue in the OP, but it may still provide some lead.
I did some digging into this one. Some observations, see if this sounds accurate:
- This problem does not exist on macos, but it is reproducible inside of an Ubuntu docker container on macos.
-
nest-cliis usingshell: truefor the spawn command. If this option is removed, I am no longer able to reproduce the issue. - A difference I am seeing is that on Linux,
shell: truespawns the shell process, and that in turn spawns a grand-child node process. On macos, even withshell: trueonly the node process is spawned. -
nest-clilistens for the 'exit' event of the spawned process to know when it's ok to restart. However, on Linux, the 'exit' message received is for the shell process, not the underlying node process.nest-cliattempts to start a new node process on the 'exit', while the underlying node process (now orphaned) is still shutting down.
UPDATE: Here's the change https://github.com/nestjs/nest-cli/compare/master...jleverenz:nest-cli:fix-cli-restart
Same here, on WSL Ubuntu nest start --watch does not wait for app to gracefully shutdown when restarting on files change. Suggestion from @jleverenz worked perfectly. Is it expected for that issue to be fixed?
