Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nodemon opens windows-kill.exe but doesn't restart process #1903

Closed
xsalazar opened this issue Jul 30, 2021 · 23 comments
Closed

nodemon opens windows-kill.exe but doesn't restart process #1903

xsalazar opened this issue Jul 30, 2021 · 23 comments

Comments

@xsalazar
Copy link

Versions

  • Versions: node@v12.2.0, win32@10.0.19043
  • nodemon -v:
$ npm view nodemon version
2.0.12
  • Operating system/terminal environment (powershell, gitshell, etc):
    • Powershell terminal
$PSVersionTable

Name                           Value
----                           -----
PSVersion                      5.1.19041.1023
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.1023
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
  • VSCode IDE
    • Version: 1.58.2 (system setup)
      Commit: c3f126316369cd610563c75b1b1725e0679adfb3
      Date: 2021-07-14T22:10:15.214Z
      Electron: 12.0.13
      Chrome: 89.0.4389.128
      Node.js: 14.16.0
      V8: 8.9.255.25-electron.0
      OS: Windows_NT x64 10.0.19043

Expected behaviour

Application would restart as normal, killing process and rerunning npm start which kicks off nodemon using nodemon.json config

Actual behaviour

Application starts as normal and I see the proper output in VSCode debug console.
image

Changing the src/index.ts (uncommenting the code to add the "Hello World" endpoint) and saving the file does the following:

  • Prints [nodemon] restarting due to changes... to the VSCode debug window
  • Opens the windows-kill.exe window, minimized on my toolbar
  • Nothing else and doesn't restart the application

The changes are not redeployed, and the only way to proceed is to kill the process manually.
image

Steps to reproduce

I have attached this sample project here as the most basic application I could get to reproduce this issue.

Manual Steps

If you wish to do this from scratch, the steps I followed were:

  • Make empty, temporary directory
  • npm init -y
  • npm i -D typescript ts-node nodemon @types/node @hapi/hapi
  • npx tsc --init
  • Create nodemon.json
{
  "watch": ["src"],
  "ext": "ts",
  "exec": "node -r ts-node/register src/index.ts"
}
  • Update package.json start script
"scripts": {
  "start": "nodemon"
},
  • Create .vscode/launch.json
{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch Server",
            "type": "pwa-node",
            "outputCapture": "std",
            "request": "launch",
            "runtimeArgs": [
                "run-script",
                "start"
            ],
            "runtimeExecutable": "npm",
            "skipFiles": [
                "<node_internals>/**"
            ],
        },
    ]
}
"use strict";

const Hapi = require("@hapi/hapi");

const init = async () => {
  const server = Hapi.server({
    port: 3000,
    host: "localhost",
  });

  server.route({
      method: 'GET',
      path: '/',
      handler: (request, h) => {
          return 'Hello World!';
      }
  });

  await server.start();
  console.log("Server running on %s", server.info.uri);
};

process.on("unhandledRejection", (err) => {
  console.log(err);
  process.exit(1);
});

init();

{
  run: false,
  system: { cwd: 'c:\\OpenSesame\\tmp\\nodemon-example' },
  required: false,
  dirs: [ 'c:\\OpenSesame\\tmp\\nodemon-example\\src' ],
  timeout: 1000,
  options: {
    dump: true,
    watch: [ 'src', re: /src/ ],
    exec: 'node -r ts-node/register src/index.ts',
    ignore: [
      '**/.git/**',
      '**/.nyc_output/**',
      '**/.sass-cache/**',
      '**/bower_components/**',
      '**/coverage/**',
      '**/node_modules/**',
      re: /.*.*\/\.git\/.*.*|.*.*\/\.nyc_output\/.*.*|.*.*\/\.sass\-cache\/.*.*|.*.*\/bower_components\/.*.*|.*.*\/coverage\/.*.*|.*.*\/node_modules\/.*.*/
    ],
    monitor: [
      'c:\\OpenSesame\\tmp\\nodemon-example\\src/**/*',
      '!**/.git/**',
      '!**/.nyc_output/**',
      '!**/.sass-cache/**',
      '!**/bower_components/**',
      '!**/coverage/**',
      '!**/node_modules/**'
    ],
    ignoreRoot: [
      '**/.git/**',
      '**/.nyc_output/**',
      '**/.sass-cache/**',
      '**/bower_components/**',
      '**/coverage/**',
      '**/node_modules/**'
    ],
    restartable: 'rs',
    colours: true,
    execMap: { py: 'python', rb: 'ruby', ts: 'ts-node' },
    stdin: true,
    runOnChangeOnly: false,
    verbose: false,
    signal: 'SIGUSR2',
    stdout: true,
    watchOptions: {},
    execOptions: {
      script: null,
      exec: 'node -r ts-node/register src/index.ts',
      args: [],
      scriptPosition: null,
      nodeArgs: undefined,
      execArgs: [],
      ext: 'ts',
      env: {}
    }
  },
  load: [Function],
  reset: [Function: reset],
  lastStarted: 0,
  loaded: [ 'c:\\OpenSesame\\tmp\\nodemon-example\\nodemon.json' ],
  watchInterval: null,
  signal: 'SIGUSR2',
  command: {
    raw: { executable: 'node -r ts-node/register src/index.ts', args: [] },
    string: 'node -r ts-node/register src/index.ts'
  }
}
@mchammer01
Copy link

👋🏻 Something similar is happening to me.
I use Node.js version 16 to run a docs site locally on my Windows 10 machine. I run commands to install all the required dependencies, and to create static assets. I can see the running server on localhost:4000 in my browser when I start it, and usually, I can make changes to the site content and immediately see my updates on localhost:4000. This is no longer happening.

windows-kill

I get a windows-kill window that remains open, and localhost:4000 is not updated with my changes. I have to kill the process and restart the server to see the latest updates. I have to resort to doing that every time I make changes to the site content, which is a bit of a nuisance.

I am not an engineer/developer but a colleague of mine who is told me that the issue is most likely to be with nodemon, and advised me to add a comment to this issue.

Can someone help?

@xsalazar
Copy link
Author

@mchammer01 we were able to work around this issue by doing the following (you mentioned you're not a developer, but maybe this will still be helpful)

  • If you have a nodemon.json config file, set "signal": "SIGKILL" or if you're launching from CLI configuration, --signal SIGKILL should have the same result

(apologies for the hard ping) @remy I noticed there was no further patches recently after the release to bundle this locally (v0.2.8), so I want to try to understand why we could still be seeing this?

@mchammer01
Copy link

@xsalazar 👋🏻 - thanks for the tip, I will definitely give your workaround a go!
Thanks again 🙇🏻 🙂

@mchammer01
Copy link

I can confirm that adding "signal": "SIGKILL" to the repo's nodemon.json file fixes the issue 😀 🎉

@remy
Copy link
Owner

remy commented Aug 12, 2021

@mchammer01 if I can get the time today, I'll push a debug version of nodemon to npm that switches to using this signal on Windows by default to see if we can nail this issue once and for all.

@remy remy added the windows label Aug 12, 2021
@mchammer01
Copy link

That would be awesome @remy, thank you so much ✨ 🙇🏻
Also, a big thank you to @xsalazar for the workaround in the mean time 🙇🏻

@mattpollard
Copy link

👋🏻 @remy, gentle bump... is this something you've been able to look into or may be able to look into soon? 🙏🏻

@LovingGarlic
Copy link

Also had this issue and the "signal": "SIGKILL" workaround worked for me as well.

@mattpollard
Copy link

One other potential workaround: we've tried starting our server with npm start -- --signal SIGKILL, and that also seems to get the correct signal to nodemon.

@remy
Copy link
Owner

remy commented Sep 22, 2021

I've been revisiting these as dropping briefly and I can't replicate at all.

Here's a screenshot showing my windows version, which is pretty darn close to the versions originally posted:

Screenshot 2021-09-22 at 13 57 44

The one big difference I noticed is that the screenshots of the OP had the node debugger attaching, which mine didn't - but I followed the directions but kept inside of powershell rather than spawning from VSCode as I wanted to ensure I had the right version.

So, either we put this down to the FAQ, or someone can provide the missing bit so I can replicate fully (sorry).

@xsalazar
Copy link
Author

@remy would you be able to see if you can replicate the issue inside VSCode? Anecdotally, this DID work prior to the windows-kill changes and only broke after, so it seems related.

@remy
Copy link
Owner

remy commented Sep 22, 2021

@xsalazar I couldn't run PowerShell 5 in VSC, it was running PS7 - I'm not in Windows often enough to know why or how to change it.

But agree - there's definitely a link to the windows-kill - but prior to that, the reports were that the sub process wouldn't shutdown - so I think it goes deeper.

I'll try VSC now - again though - I need other's help to find and solve this as I've been coming up empty on these related issues for months now.

@remy
Copy link
Owner

remy commented Sep 22, 2021

Screenshot 2021-09-22 at 22 35 55

Running in VSC, PS7, node@16, nodemon@latest - cannot replicate.

I believe there's a real problem here, but I can't replicate, so …

@xsalazar
Copy link
Author

@remy Thanks for the response; super appreciate it. I'll try to find some time this week to dig in again -- it sounds like the only thing missing from your test above is the VSCode debugger, so maybe that's where the breakdown is happening?

@immortalmind2016
Copy link
Contributor

i solved this issue inside this pr : #1938
you can check it

@remy
Copy link
Owner

remy commented Oct 18, 2021

Can people following this thread test with npm i nodemon@debug and confirm if this works or not - this is the latest change with @immortalmind2016's changes.

@peterbe
Copy link

peterbe commented Oct 18, 2021

Can people following this thread test with npm i nodemon@debug and confirm if this works or not - this is the latest change with @immortalmind2016's changes.

We tried. Technically, I remote-tried asking a Windows contributor to try npm i nodemon@debug and then she was able to use nodemon server.mjs the same way we're doing it for "unix". As of that upgrade there was no longer a need to use nodemon --signal SIGKILL server.mjs.

@remy
Copy link
Owner

remy commented Oct 19, 2021

@peterbe

We tried. Technically, I remote-tried asking a Windows contributor to try npm i nodemon@debug and then she was able to use nodemon server.mjs the same way we're doing it for "unix". As of that upgrade there was no longer a need to use nodemon --signal SIGKILL server.mjs.

Just to clarify, are you saying it's working as expected with that build?

@remy
Copy link
Owner

remy commented Oct 19, 2021

@xsalazar are you able to test with the debug build too - as you had the original problem?

@remy remy added the has PR label Oct 19, 2021
@remy remy closed this as completed in 61e7abd Oct 19, 2021
@github-actions
Copy link

🎉 This issue has been resolved in version 2.0.14 🎉

The release is available on:

Your semantic-release bot 📦🚀

@peterbe
Copy link

peterbe commented Oct 19, 2021

@remy

Just to clarify, are you saying it's working as expected with that build?

Yes.

@xsalazar
Copy link
Author

@remy Yes! This did fix this particular issue, with the sample project attached. No more windows-kill.exe hanging out while debugging through VSCode! 🎉

@GusGF
Copy link

GusGF commented Oct 31, 2021

Yes this worked for me too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants