Nodemon does not wait for process to exit before starting a new one #1508
Comments
|
Hi everyone, I guess #1501 is also related. Cheers |
|
Little update from here: Maybe it helps someone. Not sure if it fixed my environment, it did at least for now. |
|
Rolling back to |
|
Can anyone else confirm downgrading to [email protected] also works? I don't have whatever flavour of linux If .7 does indeed revert the issue, the number of commits are small enough to dig in to work out where it's going wrong: It's either in a pstree.remy release in 1.18.8 - but pstree.remy has been released from 1.1.3 to 1.1.6 since that release, but since the version isn't pinned in [email protected], I'm guessing @Cyral has got [email protected] installed (could @Cyral confirm via Otherwise it's in the 1.18.9 release which is effectively a single line. I think @dobesv could comment that single line out in their local version and re-test. Also to note: the issues that have been tag as related are only related in that they have similar or the same symptoms. The cause is very different - and thus not related to these releases. |
|
I tried downgrading to |
|
I also tried downgrading |
|
Downgrading to |
|
What appears to the be issue here is that when the process is launched using When When The bug here, I suppose, is that Alternatively, perhaps there's a way to run this through the shell that doesn't create an extra intermediate shell process, e.g. by using |
|
|
To workaround this issue you have to avoid using the |
|
This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up. |
|
This is still an issue for processes run by nodemon using the "spawn" launch method. |
|
I meant to remove the stale label last night. Anyway, I investigated this issue in my weekly twitch session and found some interesting things. (If you're interested it's here, though a little overly verbose - I suggest sped up!). Short version:
In linux (I think) spawn is one process id (which nodemon refers to as the The I don't understand how to tell from the This feels like a node issue over nodemon, but I'd need to pare down the issue even more. Importantly: does anyone have any experience understanding unix processes, node and kill signals? |
|
I believe I saw somewhere that one way to wait for all the subprocesses to exit is to wait for them to close their stdin / stdout / stderr handles. Then you as the parent will get an EOF (e.g. "close" event) on those handles. You can wait until all three handles are closed and the consider the job to have exited. This will ignore processes that explicitly close these handles themselves, but I think it's OK to assume those processes wanted to escape being controlled anyway. This article mentions this detail about the stdio streams closing when all the child processes close them or exit: https://medium.freecodecamp.org/node-js-child-processes-everything-you-need-to-know-e69498fe970a Another way is when you try to kill the process, get a list of all the subprocess ids and start monitoring them to wait for them to close, only considering the exit complete when you can no longer detect any running subprocesses. This is more work but adheres to the more strict rule of really waiting for all subprocesses to exit, including ones that close all their stdio streams. |
|
This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up. |
|
This is still an issue |
|
Also having this issue on Ubuntu 18 LTS |
|
This is an issue for me too on Mac OSX |
|
Adding label to tell stalebot to back off (I should have done this ages ago). Happy for anyone who detailed info on how to replicate to take a crack at a PR 👍 |
|
@PePe79 I also think these issues are related. |
|
This issue also occurs on MacOSX. |
|
Found a solution for this. |
|
PR live in [email protected] @AndrewOdiit this is a nice solution, I'm going to add this to the faq too 👍 |
|
This is what it took to get nodemon gracefully shutting down for me, a combination of a few things. I'm sure it could be done without node-cleanup, manually coding a lot of what that's doing, but it's a lot easier. Also const nodeCleanup = require("node-cleanup");
...
let stopping = false;
nodeCleanup((exitCode, signal) => {
// Don't call nodeCleanup.uninstall(), it needs to continue catching and ignoring signals
if (!stopping) {
stopping = true;
console.log("Application shutting down...");
myAsyncShutdown().then(() => {
console.log("Application shutdown complete.");
process.kill(process.pid, signal);
});
}
return false;
});
process.on("SIGUSR2", () => process.kill(process.pid, "SIGHUP")); |
@remy Could you take a look at this? |
|
I am still having this issue and I'm not sure how to workaround. |
|
@Clindbergh you'll need to create an issue with pared down code if you think it can be fixed (thanks). |
System information:
Expected behaviour
When I change a file,
nodemonsignals the process but does not start a new process unless the existing process exits.Actual behaviour
nodemonstarts a new process while the old process continues to run. If the old process was listening on a port, the new process might get an "address in use" error.Steps to reproduce
Check out this git repo and follow the instructions:
https://github.com/dobesv/nodemon-repro
Alternatively, just run any process that uses the
spawnmethod of launching (or maybe pass--spawn?) and does not exit when it receivesSIGUSR2.Dump
Related issues
The text was updated successfully, but these errors were encountered: