Node doesn't exit after closing watch

[EzraM]

After setting up, then closing, a watcher, the Node process doesn't exit.
Windows.

const chokidar = require('chokidar')
const options = {}
const directoryPath = srcPath
// configuration taken from webpack
const watcher = chokidar.watch(directoryPath, {
    ignoreInitial: true,
    persistent: true,
    followSymlinks: false,
    depth: 0,
    atomic: false,
    alwaysStat: true,
    ignorePermissionErrors: true,
    usePolling: options.poll ? true : undefined,
    interval: typeof options.poll === "number" ? options.poll : undefined
});
watcher.close()

[nicokaiser]

Maybe this has something to do with nested directories. We observed this with deep directories, but it worked with flat ones without subdirectories.

[DarkPark]

I confirm the problem. No nested directories are required.
A simple code to reproduce:

var chokidar = require('chokidar');

var fn = function ( name ) {
    console.log('change: ' + name);
};

var watcher = chokidar.watch('./*')
    .on('change', fn)
    .on('unlink', fn)
    .on('add',    fn);

setTimeout(function () {
    console.log('should exit!');
    watcher.close();
}, 10000);

Interesting point to note - just run the code above and wait doing nothing - it will exit the node process in 10 seconds without any problems.
It will NOT exit in case there will be some file modifications in the current dir before watcher.close. So even once change/unlink/add are triggered and this hangs the process.

[eoinmurray]

Same issue here -> quite important for us because we need many watchers to be opened and closed in a long running program, and close locks of the program

[eoinmurray]

Its the FSWatcher.unwatch which is hanging, and I think this is being called inside FSWatcher.close

    watchers.forEach((w)=>{
      console.log(`unwatching ${watchers.length}`)
      const watched = keys(w.getWatched())
      console.log('gotWatched()')
      w.unwatch(watched)
      console.log('unwatched')
    })
  })

Fails sometimes on the w.unwatch step

[es128]

Unfortunately it is most likely an issue with the underlying watch methods. I don't have high confidence that this is something that is possible to fix from within chokidar. Also likely to be highly OS-dependent. Would appreciate if anyone reporting this issue would note their OS & node version.

I would guess it's core's fs.FSWatcher#close() that's really where the problem occurs. Is anyone who is observing this issue on OS X and using fsevents?

If this is critical, try using usePolling: true and seeing what impact that has. May solve this problem, but there will be performance tradeoffs.

[philkunz]

any ETA on this one?

[es128]

Not from my side. Nobody who can reproduce this issue has provided any of the feedback I asked for to help diagnose the problem.

I have not been able to reproduce/observe the problem myself. It seems system-dependent, and as stated before, I'm not confident that once we do figure out the source that there's something chokidar could do differently to impact the outcome.

[philkunz]

here is a reproducible build: The memory event leak on top is due the current npm version and is not the source of the problem + different process

https://gitlab.com/pushrocks/smartchok/builds/4332135

the class in question using chokidar: https://gitlab.com/pushrocks/smartchok/blob/master/ts/index.ts

the testFile that produces the problem:
https://gitlab.com/pushrocks/smartchok/blob/master/test/test.ts

[philkunz]

ok, I think I found the problem... If I add the same file twice (look at the Smartchok.add() method) then chokidar doesn't close correctly. Does chokidar test internally, if the file is already watched/has been added before?

[es128]

Yes.

https://github.com/paulmillr/chokidar/blob/master/lib/nodefs-handler.js#L251-L252

[es128]

But you might be onto something in terms of watch handles somehow getting lost

[philkunz]

This commit fixed it for me: https://gitlab.com/pushrocks/smartchok/commit/0fe26b4b44f017dc2c06da618742bcbd46ca71b1

I'm only making sure only to add a path string once. If I have more findings I'll post here.