yarn
yarn copied to clipboard
yarnpkg
Error: EINVAL: invalid argument, mkdir when running `yarn install`
Bug description
This is an interesting error. Some context first. I am using Anka, a virtualization technology from Veertu to execute tasks in Continuous Integration (CI). During this process, we create a directory in the host machine that we later mount in ~/app/node_modules (the location does not really matter) to later install the dependencies there. When our CI task runs, we execute yarn install --cwd . --frozen-lockfile. This command fetches and installs the yarn dependencies as expected. But around ~30% of the time, it fails with a message similar to:
error An unexpected error occurred: "EINVAL: invalid argument, mkdir '/Users/anka/test/node_modules/@turf/bbox/node_modules'".
Sometimes the error is with lstat isntead of mkdir.
The directory that can't be created isn't always the same.
If I later execute:
# check if the directory exists. It does not, as expected because mkdir failed.
$ ls '/Users/anka/test/node_modules/@turf/bbox/node_modules'
ls: /Users/anka/test/node_modules/@turf/bbox/node_modules: No such file or directory
# Now I try to create the dir. It works!
$ mkdir '/Users/anka/test/node_modules/@turf/bbox/node_modules'
$ ls '/Users/anka/test/node_modules/@turf/bbox/node_modules'
Some info about the system:
Arguments:
/Users/anka/.nvm/versions/node/v13.2.0/bin/node /usr/local/Cellar/yarn/1.22.0/libexec/bin/yarn.js install --cwd . --frozen-lockfile --verbose
PATH:
/Users/anka/.gem/ruby/2.5.7/bin:/opt/rubies/2.5.7/lib/ruby/gems/2.5.0/bin:/opt/rubies/2.5.7/bin:/Users/anka/.nvm/versions/node/v13.2.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Yarn version:
1.22.0
Node version:
13.2.0
Platform:
darwin x64
Trace:
Error: EINVAL: invalid argument, mkdir '/Users/anka/test/node_modules/@turf/bbox/node_modules'
The interesting part is that this never happens if the yarn dependencies are installed in a directory that isn't mounted.
I have checked the permissions in both host and VM and yarn should be able to create directories. I have also run yarn --verbose, but the information provided in the logs isn't helpful.
What is the expected behavior?
I would expect yarn to be able to install the dependencies without issues.
I have seen some other issues reporting EINVAL errors, but those seem to happen in Windows. I wonder if they can be somehow related. Are those Windows reports using WSL? Maybe yarn or the mkdir lib don't work well with virtualized environments?
Happy to provide more info or try possible solutions!
I have been able to trace it with dtruss and I can share the logs if needed.
Veertu support has found this is a bug we can replicate directly with FUSE (not using Anka). We've reported it to FUSE support and are waiting on them to fix it.
It looks like we've been hitting this in an osxfuse mount on macOS as well.
I caught it in dtruss:
83639/0xa93b9: mkdir("/XXX/node_modules/@babel/node/node_modules/@babel\0", 0x1ED, 0x0) = -1 Err#22
83639/0xa93ba: mkdir("/XXX/node_modules/@babel/node/node_modules\0", 0x1ED, 0x0) = 0 0
22 being EINVAL.
It looks like yarn might be occasionally issuing mkdir out of order, given the second mkdir succeeds.
Veertu support has found this is a bug we can replicate directly with FUSE (not using Anka). We've reported it to FUSE support and are waiting on them to fix it.
@NorseGaud do you have a link to that issue/report?
Veertu support has found this is a bug we can replicate directly with FUSE (not using Anka). We've reported it to FUSE support and are waiting on them to fix it.
@NorseGaud do you have a link to that issue/report?
No, we reported it directly to Benjamin Fleischer. I've linked him to this issue to investigate. It's possible @chadaustin's context will help determine the cause. I believe the last message on this issue was an inability to reproduce. Any and all details on reproducing this would be helpful for Benjamin.
One thing I noted to Chad was that I'd expect the out-of-order/racing mkdirs to result in ENOENT rather than EINVAL. I suspect that is the heart of the problem.
still an issue in 2022 its from a login script performing yarn config commands try commenting them all out as this pkg has changed its behavior yarn doesnt hold water anymore
It is clearly still happening with GHA WSL, see https://github.com/ansible/ansible-language-server/runs/7976132662?check_suite_focus=true#step:11:119 -- still, it is not directly reproducible. Does anyone know any tricks that could help for avoiding this problem? ... other than not using WSL, because the whole purpose of this pipeline was to test WSL behavior.
