Nodemon: Windows and lack of signals -> graceful shutdown

[TimNZ]

nodemon sends a SIGUSR2 signal on terminate that Windows doesn't handle.

Any using nodemon on windows and has a tidy alternative for graceful shutdown?

Production deploy will be linux, but I dev on Windows and want to test.

I can think of some things but they would require modifying nodemon.

[remy]

I'm open to ideas if there's a clean way to send a exit signal to the child
process in windows, I'd be listening. Equally, if you think you can create
a pull request with the change that helps even more (windows doesn't
feature in my main machines, so it's never quickly to hand).

On 16 January 2013 21:09, TimNZ [email protected] wrote:

nodemon sends a SIGUSR2 signal on terminate that Windows doesn't handle.

Any using nodemon on windows and has a tidy alternative for graceful
shutdown?

Production deploy will be linux, but I dev on Windows and want to test.

I can think of some things but they would require modifying nodemon.

—
Reply to this email directly or view it on GitHubhttps://github.com/remy/nodemon/issues/140.

[TimNZ]

Umm, I don't know about 'clean' :)

I am brain storming here:

• A 'kill' file that nodemon creates and the app periodically scans for. The nodemon removes file and restarts app as per normal process, kills process within X seconds as it does now if it doesn't kill itself.
• Post messages via IPC mechanism

I know it is far from ideal, but if nodemon implemented a messaging protocol of some sort, then at least people can choose whether to be nodemon aware in the monitored app, plus it gives flexibility for sending additional data with the message, even allowing app to come back and say "don't kill me, I don't care about that change".

[rjanicek]

In run.js around line 35, could fork be used instead of spawn? Then built in communication channel could be used to send kill message to child. child.send(message).

[rjanicek]

Tested replacing spawn wit fork and many tests broke so not a reasonable option.

[gwilakers]

So nothing on this then?

[stale[bot]]

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.
Thank you for contributing <3

[ghost]

I'd like this to be reopened.

At least note the limitation in the docs. I spent most of this morning trying to figure out why I wasn't seeing the SIGUSR2 signal in my app.

[remy]

I'm not reopening a 5 year old issue. The code that caused this bug has long gone and it's extremely likely you're seeing something new. Can you file a new issue with full details on how to replicate, ideally with any investigation too.

[ghost]

@remy It looks like the issue was closed a month and a half ago as wontfix, so it didn't appear as though it was gone. From the discussion, it sounds like the documented solution for a graceful shutdown of listening for a SIGUSR2 signal is not actually supported on Windows.

Are you saying that this is no longer the case?

[remy]

I've no idea, I use Windows on the odd occasion to debug nodemon issues, otherwise I'm a Mac user. So when windows issues come up, I've had to rely in the past on others to give me details.

The wontfix was because the issue was idle, and like I said, the code that the original issue was raised on doesn't exist due to redactors over the (five) years since it was originally raised.

But, as I said, if you raise a new issue, with details on how to replicate then I can investigate. I'm doing some windows test and bug fixing today too.