getting EADDRINUSE error when using start with watch mode with an async beforeApplicationShutdown

[micalevisk]

Is there an existing issue for this?

• 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

issue_demo.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 

2. npm ci
3. npm run start:dev
4. change any source file
5. 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
• Linux

[kamilmysliwiec]

Would you like to create a PR to address this issue?

[micalevisk]

I don't know how to fix that yet

[micalevisk]

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:

demo.mp4

And this is related with #1487 So I believe that if we manage to fix that one, we'll fix this issue accordingly.

[kos984]

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

[TylerOrtiz]

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.

[andreasciamanna]

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.

[jleverenz]

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-cli is using shell: true for 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: true spawns the shell process, and that in turn spawns a grand-child node process. On macos, even with shell: true only the node process is spawned.
• nest-cli listens 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-cli attempts 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 master...jleverenz:nest-cli:fix-cli-restart

[quallrum]

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?

[kamilmysliwiec]

Let's track this here #2522