Skip to content
This repository has been archived by the owner on Oct 16, 2021. It is now read-only.

bufferutil fails to build on z/OS (no such file or directory, uv_cwd) #165

Open
ind1go opened this issue Oct 22, 2020 · 11 comments
Open

bufferutil fails to build on z/OS (no such file or directory, uv_cwd) #165

ind1go opened this issue Oct 22, 2020 · 11 comments

Comments

@ind1go
Copy link

ind1go commented Oct 22, 2020

  • Version: v12.13.0
  • Platform: OS/390 MV28 26.00 04 3906
  • Subsystem:

The module bufferutil is fairly heavily used by Websockets clients in Node.js.

It fails to build on z/OS, during node-gyp.

> bufferutil@4.0.1 install [...]/node_modules/bufferutil
> node-gyp-build

gyp ERR! UNCAUGHT EXCEPTION
gyp ERR! stack Error: ENOENT: no such file or directory, uv_cwd
gyp ERR! stack     at process.cwd (internal/process/main_thread_only.js:42:25)
gyp ERR! stack     at setopts (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/glob/common.js:93:21)
gyp ERR! stack     at new Glob (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/glob/glob.js:135:3)
gyp ERR! stack     at Function.glob.hasMagic (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/glob/glob.js:101:11)
gyp ERR! stack     at rimraf (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/rimraf/rimraf.js:62:36)
gyp ERR! stack     at clean (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/lib/clean.js:11:3)
gyp ERR! stack     at Object.self.commands.<computed> [as clean] (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/lib/node-gyp.js:41:37)
gyp ERR! stack     at run (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:80:30)
gyp ERR! stack     at processTicksAndRejections (internal/process/task_queues.js:75:11)
gyp ERR! System OS/390 26.00
gyp ERR! command "/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/bin/node" "/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
internal/process/main_thread_only.js:42
    cachedCwd = binding.cwd();
                        ^

Error: ENOENT: no such file or directory, uv_cwd
    at process.cwd (internal/process/main_thread_only.js:42:25)
    at errorMessage (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:127:28)
    at issueMessage (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:133:3)
    at process.<anonymous> (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:117:3)
    at process.emit (events.js:210:5)
    at process._fatalException (internal/process/execution.js:150:25) {
  errno: -129,
  code: 'ENOENT',
  syscall: 'uv_cwd'
}
@ind1go ind1go changed the title bufferutil fails to build (no such file or directory, uv_cwd) bufferutil fails to build on z/OS (no such file or directory, uv_cwd) Oct 23, 2020
@IgorTodorovskiIBM
Copy link
Collaborator

Can you check if /ZOS203 is a symlink.

ls -l / | grep ZOS203

If so, there is a fix for this in v12.16.1 and above.

@ind1go
Copy link
Author

ind1go commented Oct 24, 2020

Hi @IgorTodorovskiIBM, thanks for getting back.

Unfortunately not:

$> ls -l / | grep ZOS203
drwxr-xr-x    16 BPXROOT  OMVS        8192 Mar 10  2020 ZOS203

I then ran explicitly with the latest Node version we have, too (didn't realise that our 'latest' symlink is not up-to-date!):

$> /usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/npm install bufferutil

> bufferutil@4.0.1 install [...]/node_modules/bufferutil
> node-gyp-build

gyp ERR! UNCAUGHT EXCEPTION
gyp ERR! stack Error: ENOENT: no such file or directory, uv_cwd
gyp ERR! stack     at process.cwd (internal/process/main_thread_only.js:42:25)
gyp ERR! stack     at setopts (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/glob/common.js:93:21)
gyp ERR! stack     at new Glob (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/glob/glob.js:135:3)
gyp ERR! stack     at Function.glob.hasMagic (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/glob/glob.js:101:11)
gyp ERR! stack     at rimraf (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/rimraf/rimraf.js:70:36)
gyp ERR! stack     at clean (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/lib/clean.js:11:3)
gyp ERR! stack     at Object.self.commands.<computed> [as clean] (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/lib/node-gyp.js:41:37)
gyp ERR! stack     at run (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:80:30)
gyp ERR! stack     at processTicksAndRejections (internal/process/task_queues.js:75:11)
gyp ERR! System OS/390 26.00
gyp ERR! command "/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/bin/node" "/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
internal/process/main_thread_only.js:42
    cachedCwd = binding.cwd();
                        ^

Error: ENOENT: no such file or directory, uv_cwd
    at process.cwd (internal/process/main_thread_only.js:42:25)
    at errorMessage (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:127:28)
    at issueMessage (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:133:3)
    at process.<anonymous> (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:117:3)
    at process.emit (events.js:210:5)
    at process._fatalException (internal/process/execution.js:150:25) {
  errno: -129,
  code: 'ENOENT',
  syscall: 'uv_cwd'
}

@IgorTodorovskiIBM
Copy link
Collaborator

IgorTodorovskiIBM commented Oct 26, 2020 •
edited
Loading

Hmm, I see /ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.13.0-os390-s390x/bin/node in the output.

If you set:

export PATH="/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/:$PATH"

and then run npm install does it work?

@ind1go
Copy link
Author

ind1go commented Oct 26, 2020

You're right, seeing v12.18.0 and v12.13.0 is unexpected...

Unfortunately I think it's the same when consistently using v12.18.0 throughout.

$> export PATH="/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/:$PATH"
$> where node
/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/node
$> where npm
/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/npm
$> npm install -S bufferutil

> bufferutil@4.0.1 install [...]/node_modules/bufferutil
> node-gyp-build

gyp ERR! UNCAUGHT EXCEPTION
gyp ERR! stack Error: ENOENT: no such file or directory, uv_cwd
gyp ERR! stack     at process.wrappedCwd [as cwd] (internal/bootstrap/switches/does_own_process_state.js:128:26)
gyp ERR! stack     at setopts (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/glob/common.js:93:21)
gyp ERR! stack     at new Glob (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/glob/glob.js:135:3)
gyp ERR! stack     at Function.glob.hasMagic (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/glob/glob.js:101:11)
gyp ERR! stack     at rimraf (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/rimraf/rimraf.js:70:36)
gyp ERR! stack     at clean (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/lib/clean.js:11:3)
gyp ERR! stack     at Object.self.commands.<computed> [as clean] (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/lib/node-gyp.js:41:37)
gyp ERR! stack     at run (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:80:30)
gyp ERR! stack     at processTicksAndRejections (internal/process/task_queues.js:79:11)
gyp ERR! System OS/390 26.00
gyp ERR! command "/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/node" "/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
internal/bootstrap/switches/does_own_process_state.js:128
  cachedCwd = rawMethods.cwd();
                         ^

Error: ENOENT: no such file or directory, uv_cwd
    at process.wrappedCwd [as cwd] (internal/bootstrap/switches/does_own_process_state.js:128:26)
    at errorMessage (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:127:28)
    at issueMessage (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:133:3)
    at process.<anonymous> (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:117:3)
    at process.emit (events.js:315:20)
    at process._fatalException (internal/process/execution.js:165:25) {
  errno: -129,
  code: 'ENOENT',
  syscall: 'uv_cwd'
}

@IgorTodorovskiIBM
Copy link
Collaborator

Ok, it seems /usr is a symbolic link to /ZOS203. Just to rule it out, does export PATH="/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/:$PATH" help?

uv_cwd calls the c function getcwd() to get the current working dir. What is your current working dir? Is there anything unusual about it? Is there a symlink to an environment variable? Is it a mounted location?

If you do rm -rf node_modules from the current dir, does rm report any errors? The reason I ask is that another client had a similar issue reflected with rm on the node_modules dir.

@ind1go
Copy link
Author

ind1go commented Oct 26, 2020

Here we go with that export:

$> export PATH="/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/:$PATH"
$> where node
/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/node
$> where npm
/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/npm
$> npm install -S bufferutil

> bufferutil@4.0.1 install /u/bencox/bufferutil-test/node_modules/bufferutil
> node-gyp-build

gyp ERR! UNCAUGHT EXCEPTION
gyp ERR! stack Error: ENOENT: no such file or directory, uv_cwd
gyp ERR! stack     at process.wrappedCwd [as cwd] (internal/bootstrap/switches/does_own_process_state.js:128:26)
gyp ERR! stack     at setopts (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/glob/common.js:93:21)
gyp ERR! stack     at new Glob (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/glob/glob.js:135:3)
gyp ERR! stack     at Function.glob.hasMagic (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/glob/glob.js:101:11)
gyp ERR! stack     at rimraf (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/rimraf/rimraf.js:70:36)
gyp ERR! stack     at clean (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/lib/clean.js:11:3)
gyp ERR! stack     at Object.self.commands.<computed> [as clean] (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/lib/node-gyp.js:41:37)
gyp ERR! stack     at run (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:80:30)
gyp ERR! stack     at processTicksAndRejections (internal/process/task_queues.js:79:11)
gyp ERR! System OS/390 26.00
gyp ERR! command "/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/bin/node" "/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
internal/bootstrap/switches/does_own_process_state.js:128
  cachedCwd = rawMethods.cwd();
                         ^

Error: ENOENT: no such file or directory, uv_cwd
    at process.wrappedCwd [as cwd] (internal/bootstrap/switches/does_own_process_state.js:128:26)
    at errorMessage (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:127:28)
    at issueMessage (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:133:3)
    at process.<anonymous> (/ZOS203/usr/lpp/IBM/cnj/v12r0/IBM/node-v12.18.0-os390-s390x/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js:117:3)
    at process.emit (events.js:315:20)
    at process._fatalException (internal/process/execution.js:165:25) {
  errno: -129,
  code: 'ENOENT',
  syscall: 'uv_cwd'
}

You're right about that symlink from /usr:

$> ls -al /usr
lrwxrwxrwx   1 BPXROOT  CPSSRAG       12 Feb 22  2008 /usr -> $VERSION/usr

Regarding the CWD: I've not redacted the output this time so you can see where the project is, and I'm running the command from the root of the project, i.e /u/bencox/bufferutil-test. There are no symlinks in that path. In terms of whether it's a mounted location... I'm not sure I rightly know the answer to that, but I can tell you that /u/bencox is its own zFS aggregate, if that helps.

No issues reported by rm -rf node_modules.

@IgorTodorovskiIBM
Copy link
Collaborator

IgorTodorovskiIBM commented Oct 27, 2020 •
edited
Loading

Ok, npm install executes node-gyp.js rebuild, which perform node-gyp clean first and is attempting to remove the build dir, but it appears to be failing on process.cwd. This could be a file system related issue.

My guess is that if you run: node-gyp clean under node_modules/bufferutil you will be able reproduce it.

Are you able to run npm install in another file system, such as in /tmp? Can you also add --verbose=silly to get more info

Can you also confirm if you have $HOME set?

@ind1go
Copy link
Author

ind1go commented Oct 27, 2020

I struggled to do as instructed (run node-gyp clean under node_modules/bufferutil) because that directory didn't already exist. I thought it may be interesting to you to know the content of node_modules immediately after running npm install -S bufferutil as it looks fairly inconsistent to me:

/u/bencox/bufferutil-test/node_modules:>ls -al
total 48
drwxr-xr-x   3 BENCOX   TSOUSER     8192 Oct 27 22:43 .
drwxr-xr-x   3 BENCOX   TSOUSER     8192 Oct 27 22:43 ..
drwxr-xr-x   2 BENCOX   TSOUSER     8192 Oct 27 22:43 .bin

And what's in .bin?

/u/bencox/bufferutil-test/node_modules/.bin:>ls -al
total 32
drwxr-xr-x   2 BENCOX   TSOUSER     8192 Oct 27 22:43 .
drwxr-xr-x   3 BENCOX   TSOUSER     8192 Oct 27 22:43 ..
lrwxrwxrwx   1 BENCOX   TSOUSER       24 Oct 27 22:43 node-gyp-build -> ../node-gyp-build/bin.js
lrwxrwxrwx   1 BENCOX   TSOUSER       29 Oct 27 22:43 node-gyp-build-optional -> ../node-gyp-build/optional.js
lrwxrwxrwx   1 BENCOX   TSOUSER       31 Oct 27 22:43 node-gyp-build-test -> ../node-gyp-build/build-test.js

So none of those symlinks have their target available.

Anyway, that aside, I then went on and ran a manual mkdir bufferutil followed by node-gyp clean in that directory, which perhaps unsurprisingly succeeded because there was nothing to clean:

/u/bencox/bufferutil-test/node_modules/bufferutil:>node-gyp clean
gyp info it worked if it ends with ok
gyp info using node-gyp@5.1.0
gyp info using node@12.18.0 | os390 | s390x
gyp info ok

I then moved into /tmp, made a new project and tried to install bufferutil. Immediately, I had a different result - node-gyp was looking for and failing to find Python. After adding Python to PATH, I got the following error:

/tmp/bufferutil-test:>npm install -S bufferutil

> bufferutil@4.0.1 install /MV28/tmp/bufferutil-test/node_modules/bufferutil
> node-gyp-build

make: Entering directory '/MV28/tmp/bufferutil-test/node_modules/bufferutil/build'
  CC(target) Release/obj.target/bufferutil/src/bufferutil.o
FSUM3224 njsc: Fatal error in /usr/lpp/IBM/cnj/v12r0/njsc/exe/cnjdrvr: signal 9 received.
bufferutil.target.mk:107: recipe for target 'Release/obj.target/bufferutil/src/bufferutil.o' failed
make: *** [Release/obj.target/bufferutil/src/bufferutil.o] Error 251
make: Leaving directory '/MV28/tmp/bufferutil-test/node_modules/bufferutil/build'

So it looks like the installation is getting much further, and the issue is specific to my home directory.

I would like to get bufferutil working so perhaps let's go back to the problem with make later on (if you're happy to help continuing diagnosis - it's really appreciated!) but for now let's stick to what's going wrong when in my home directory. Here's the --loglevel silly outputs:

homedir-install-bufferutil-silly.log
tmp-install-bufferutil-silly.log

I didn't spot anything telltale in the diff - hoping you'll be able to see something.

@ind1go
Copy link
Author

ind1go commented Oct 28, 2020

FWIW I'm able to remote debug using VSCode, right to the line in node-gyp where it goes wrong - except of course it dives into the natives and then libuv. Let me know if there's something I can look out for or trigger while debugging that will help to work out what the issue is.

@IgorTodorovskiIBM
Copy link
Collaborator

IgorTodorovskiIBM commented Oct 28, 2020 •
edited
Loading

Regarding FSUM3224 njsc: Fatal error in /usr/lpp/IBM/cnj/v12r0/njsc/exe/cnjdrvr: signal 9 received.

cnjdrvr is an external link to CNJDRVR which is a member in the C/C++ compiler PDS. You can find your compiler PDS if you grep steplib in your njsc.cfg. Does your userid have read access to that PDS or does it even exist? The default dataset is CBC.HAL9C00.SCNJCMP.
More details here on the compiler setup: http://publibfp.boulder.ibm.com/epubs/pdf/i1355010.pdf

Just curious, what is your umask setting on the system?

Do you have a $HOME environment variable?

If you do a git clone https://github.com/websockets/bufferutil from your home dir and cd to bufferutil. You can issue:
node-gyp configure followed by node-gyp build

Then you can try node-gyp clean. Does this reproduce the problem?

@ind1go
Copy link
Author

ind1go commented Oct 28, 2020

Does your userid have read access to that PDS or does it even exist?

$> cat /usr/lpp/IBM/cnj/v12r0/njsc/etc/njsc.cfg | grep steplib
              steplib           = cbc.HAL9C00.scnjcmp

That library doesn't exist, but I think PP.NODEJS.V120.SCNJCMP is probably the analog on our systems so I'll raise a ticket to get njsc.cfg updated - thank you. The info from the program directory doesn't appear in the Knowledge Center and the references to the PD are pretty easy to miss, so I think that's been neglected.

I tried adding PP.NODEJS.V120.SCNJCMP to my $STEPLIB env var but that didn't seem to have any effect - presumably that's expected.

Just curious, what is your umask setting on the system?

$> umask
0022

Do you have a $HOME environment variable?

$> echo $HOME
/u/bencox

node-gyp configure followed by node-gyp build

Then you can try node-gyp clean. Does this reproduce the problem?

Unfortunately not, it definitely seems to be something to do with being a spawned process.

Following on from that, I took the following debug trace using NODE_DEBUG=child_process:

CHILD_PROCESS 84410730: spawn [ 'sh', '-c', 'node-gyp-build' ] {
  cwd: '/u/bencox/bufferutil-test/node_modules/bufferutil',
  env: {
    ...lots of env vars...
  },
  stdio: [ 0, 1, 2 ]
}
CHILD_PROCESS 525612: spawn [ '/bin/sh', '-c', 'node-gyp-build-test' ] {
  cwd: null,
  env: null,
  gid: undefined,
  uid: undefined,
  shell: true,
  windowsHide: false,
  windowsVerbatimArguments: false
}
CHILD_PROCESS 525612: spawn [ 'node-gyp', 'rebuild' ] { stdio: 'inherit' }

So there are 4 processes at work during this - npm, and then the child processes of node-gyp-build, node-gyp-build-test and node-gyp rebuild.

Note that in terms of what child_process thinks it's submitting, the node-gyp-build has a CWD set... but if I evaluate process.env() in any of the processes apart from the npm process, they throw ENOENT. The CWD is 'lost' in that first spawn.

I'm going to see whether I can get a minimal spawn scenario together (outside of npm and node-gyp) to see whether that reproduces the issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ind1go @IgorTodorovskiIBM