Unable to update nx on windows with native code

[Cammisuli]

Current behaviour

Updating Nx when the daemon is started causes issues with unlinking the .node file.

Expected behaviour

The daemon should stop itself and release the handle when it notices that node_modules are being changed.

Originally posted by @atsjo in #15377 (comment)

[atsjo]

as a sidenote, I have disabled the daemon in my workspace, and still this happens... I know it's started/initialized when starting (I could see the flashing cmd windows until recently). I thought it shut down after that, but I guess it's still running in the background unused... If it actually shuts down after init, then trying to stop it when node_modules changes will have no effect. But it should be easy to see which process keeps the lock via process monitor or similar...

[Cammisuli]

If it's started, it wont shut down if you change the nx.json setting. You should be able to run nx daemon --stop and that will definitely not start it again.

[atsjo]

I have disabled it via useDaemonProcess=false in nx.json below taskRunnerOptions. So I guess that only implies that it should not be used for the task runner....

[Cammisuli]

yea, which is everything that nx does.

If the daemon is disabled (you can confirm by running nx daemon) can you run npm install?

[atsjo]

yarn nx daemon returns:

Nx Daemon is not running.

I think you can easily find it via process explorer from sysinternals.... (from what I remember many years ago). At least you can test with daemon disabled as I have... The daemon runs in it's own process, so all handles should be closed when process exits. But maybe Nx console itself holds a handle... So the daemon was not running when I tested this, pretty sure disabling nx console would also have fixed it, but I first tried with disabling native hasher...

[atsjo]

just verified it again during 15.8.3->15.8.4 upgrade.

➤ YN0000: ┌ Link step
➤ YN0001: │ Error: EPERM: operation not permitted, unlink 'C:\Users\atles\source\repos\teve-no\task4s\node_modules\@nrwl\nx-win32-x64-msvc\nx.win32-x64-msvc.node'

even when daemon is not running (tested via yarn nx daemon)
however: disabling nx console plugin resolves it... the same does disabling native hasher...
so I would assume nx-console itself uses the hasher in some way, and locks the file...

[Cammisuli]

Yea, you're right @atsjo. The Nx language server uses the daemonClient behind the scenes and remains open depending on the IDE/editor.

I've added support to stop the daemon when doing nx migrate, but we'll have close whatever instance has nx console running first.

[atsjo]

Ok. I have been running with the daemon disabled for a long time now, was very unstable to build, but tried again now, and can't make it work at all... I ensure it is running, and run: yarn nx run-many --target=build
the result is this

>  NX   Failed to start or connect to the Nx Daemon process.

   
   Messages from the log:
   [NX Daemon Server] - 2023-03-06T20:32:51.908Z - Time taken for 'total for creating and serializing project graph' 0.527899980545044ms
   [NX Daemon Server] - 2023-03-06T20:32:51.908Z - Closed a connection. Number of open connections: 2
   [NX Daemon Server] - 2023-03-06T20:32:51.908Z - Done responding to the client project-graph
   [NX Daemon Server] - 2023-03-06T20:32:53.624Z - Established a connection. Number of open connections: 3
   [NX Daemon Server] - 2023-03-06T20:32:53.625Z - Closed a connection. Number of open connections: 2
   [NX Daemon Server] - 2023-03-06T20:32:53.626Z - Established a connection. Number of open connections: 3
   [NX Daemon Server] - 2023-03-06T20:32:53.632Z - [REQUEST]: Client Request for Project Graph Received
   [NX Daemon Server] - 2023-03-06T20:32:53.632Z - [REQUEST]: Responding to the client. project-graph
   [NX Daemon Server] - 2023-03-06T20:32:53.636Z - Time taken for 'total for creating and serializing project graph' 0.2692999839782715ms
   [NX Daemon Server] - 2023-03-06T20:32:53.636Z - Done responding to the client project-graph
   [NX Daemon Server] - 2023-03-06T20:32:53.720Z - [REQUEST]: Client Request for Project Graph Received
   [NX Daemon Server] - 2023-03-06T20:32:53.720Z - [REQUEST]: Responding to the client. project-graph
   [NX Daemon Server] - 2023-03-06T20:32:53.727Z - Time taken for 'total for creating and serializing project graph' 0.39980000257492065ms
   [NX Daemon Server] - 2023-03-06T20:32:53.728Z - Done responding to the client project-graph
   [NX Daemon Server] - 2023-03-06T20:32:53.757Z - [REQUEST]: Client Request for Project Graph Received
   [NX Daemon Server] - 2023-03-06T20:32:53.758Z - [REQUEST]: Responding to the client. project-graph
   [NX Daemon Server] - 2023-03-06T20:32:53.765Z - Time taken for 'total for creating and serializing project graph' 0.5737999677658081ms
   [NX Daemon Server] - 2023-03-06T20:32:53.766Z - Done responding to the client project-graph
   [NX Daemon Server] - 2023-03-06T20:32:53.806Z - Closed a connection. Number of open connections: 2

Ensured the daemon was running before build, and after this, it says it's not running...

If I try to use yarn nx reset, the result is this:

Error: ENOTEMPTY: directory not empty, rmdir '\\?\C:\Users\atles\source\repos\teve-no\task4s\node_modules\.cache\nx\d'
    at Object.rmdirSync (node:fs:1226:10)
    at _rmdirSync (node:internal/fs/rimraf:260:21)
    at rimrafSync (node:internal/fs/rimraf:193:7)
    at node:internal/fs/rimraf:253:9
    at Array.forEach (<anonymous>)
    at _rmdirSync (node:internal/fs/rimraf:250:7)
    at rimrafSync (node:internal/fs/rimraf:193:7)
    at Object.rmSync (node:fs:1275:10)
    at removeSync (C:\Users\atles\source\repos\teve-no\task4s\node_modules\fs-extra\lib\remove\index.js:11:6)
    at Object.resetHandler (C:\Users\atles\source\repos\teve-no\task4s\node_modules\nx\src\command-line\reset.js:14:31) {
  errno: -4051,
  syscall: 'rmdir',
  code: 'ENOTEMPTY',
  path: '\\\\?\\C:\\Users\\atles\\source\\repos\\teve-no\\task4s\\node_modules\\.cache\\nx\\d'
}

I reported my problems here: #12237
At that point, it was just unstable, but now it never works....

[Cammisuli]

Thanks for your patience @atsjo, the linked PR should fix the issue with not being able to remove the directory.

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.