You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is the fact that {background: true} as a default option makes express:stop not to wait until the server stopped (and hands the task back to grunt) and then later express:dev tries to start a server that it is not yet shut down?
I experience the issue when my watch task runs the default grunt task. It stops the server, builds my app which takes 2-3 seconds, then start the server, gets the error EADDRINUSE (as stop didn't happen yet) and then - after that - I get prompted "Stopping Express Server" - so stop seams to happen after start, that'swhy the server is not running after the first time the watcher triggered the process.
I would think a "restart" option that starts OR restarts the service would be awesome.
This issue seems to arise with new versions of node. Processes spun up by newer versions of node don't respond to SIGTERM in the same way that they used to. I've put up a PR that I would expect to merge as soon as I run a few more checks (see #99)---it solves the EADDRINUSE issue. If you'd like, feel free to try it out and follow up!
In the mean time, if you need a quick fix to stop the process: run ps -a | grep node and see what the process id is for your sticky processes. Then kill -9 {pid here}.
I refer to #16
Is the fact that {background: true} as a default option makes express:stop not to wait until the server stopped (and hands the task back to grunt) and then later express:dev tries to start a server that it is not yet shut down?
I experience the issue when my watch task runs the default grunt task. It stops the server, builds my app which takes 2-3 seconds, then start the server, gets the error EADDRINUSE (as stop didn't happen yet) and then - after that - I get prompted "Stopping Express Server" - so stop seams to happen after start, that'swhy the server is not running after the first time the watcher triggered the process.
I would think a "restart" option that starts OR restarts the service would be awesome.
This is my configuration:
My default task looks like that
The text was updated successfully, but these errors were encountered: