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

install breaks #63

Closed
iljavs opened this issue May 27, 2021 · 4 comments · Fixed by esy/esy#1386
Closed

install breaks #63

iljavs opened this issue May 27, 2021 · 4 comments · Fixed by esy/esy#1386

Comments

@iljavs
Copy link

iljavs commented May 27, 2021

I tried to follow the quick start install instructions. didn't work :(:
ilja@meatdripper:~/dream/example/2-middleware$ npm install esy && npx esy

esy@0.6.10 postinstall /home/ilja/dream/example/2-middleware/node_modules/esy
node -e "process.env['OCAML_VERSION'] = process.platform == 'linux' ? '4.10.1002-musl.static.flambda': '4.10.0'; process.env['OCAML_PKG_NAME'] = 'ocaml'; require('./postinstall.js')"

importing: esy-2c95689b
Done!
npm WARN saveError ENOENT: no such file or directory, open '/home/ilja/dream/example/2-middleware/package.json'
npm notice created a lockfile as package-lock.json. You should commit this file.
npm WARN enoent ENOENT: no such file or directory, open '/home/ilja/dream/example/2-middleware/package.json'
npm WARN 2-middleware No description
npm WARN 2-middleware No repository field.
npm WARN 2-middleware No README data
npm WARN 2-middleware No license field.

  • esy@0.6.10
    added 1 package and audited 1 package in 4.082s
    found 0 vulnerabilities

info esy 0.6.10 (using esy.json)
info checking https://github.com/ocaml/opam-repository for updates...
info checking https://github.com/esy-ocaml/esy-opam-override for updates...
info resolving esy packages: done
info solving esy constraints: done
info resolving npm packages: done
info fetching: done
.... installing @opam/bigarray-overlap@opam:0.2.0@d8a38f4aesy: internal error, uncaught exception:
Unix.Unix_error(Unix.EACCES, "rename", "/home/ilja/.esy/source/s/yarn_pkg_config__9829fc81")
Raised at file "src/core/lwt.ml", line 2999, characters 20-29
Called from file "src/unix/lwt_main.ml", line 26, characters 8-18
Called from file "esy-lib/Cli.re", line 264, characters 9-28
Called from file "cmdliner_term.ml", line 25, characters 19-24
Called from file "cmdliner.ml", line 25, characters 27-34
Called from file "cmdliner.ml", line 116, characters 32-39
.... installing @opam/cstruct@opam:6.0.0@c77fb059ilja@meatdripper:~/dream/example/2-middleware$

@aantron
Copy link
Owner

aantron commented May 27, 2021

Heya, this looks like a likely upstream error in esy. See esy/esy#1097. The only thing that worries me is that in your case, the error occurred in ~/.esy, whereas I've only seen it on Windows and in ./_esy so far. Trying again often works. I'm guessing that since you issued the commands manually, however, trying again didn't work in your case.

cc @ManasJayanth

What happens if you delete ~/.esy, re-clone the Dream repo, and try again? Also, what system are you on?

@ManasJayanth
Copy link
Contributor

ManasJayanth commented May 29, 2021

Thanks for the report. Is there a way to reproduce this? Unfortunately, I can't reproduce this locally. This is a known issue and the challenge has been to reproduce this consistently :/

@aantron
Copy link
Owner

aantron commented May 30, 2021

@ManasJayanth The next time I get it, I'll try to reproduce it with a dev version of esy. When I get it, I can usually reproduce it over a stretch of time, so hopefully we can finally at least diagnose this. However, I don't know how long it will be until it occurs.

ManasJayanth added a commit to esy/esy that referenced this issue Jan 6, 2022
Retry rename on EACCES

This PR retries `rename` upon getting `EACCES`. I've included data about how many retries are likely necessary.

On my system (WSL1 Ubuntu 20.04, omitting hardware details), the `EACCES` issue makes it impossible to use esy to install any of the Dream examples or use Dream's quick start. As the data below shows, every installation is expected to fail with `EACCES`, if it is not worked around.

The underlying `EACCES` issue seems to be a long-standing problem on WSL1 (microsoft/WSL#1529, microsoft/WSL#3395), and I think we do have to work around it in esy. I'm not sure what is causing the `EACCES` exactly. I think there are two main classes of possibilities:

- Self-interaction between esy's opened file descriptors and `rename`. I think the self-interaction is due to WSL rather than Lwt or another library. Since I compiled esy on WSL, it is using Lwt's Unix (rather than Windows) C code. Since the Unix code seems to work fine on Linux and Mac, this suggests a WSL issue.
- Interaction between esy and file indexers or other proceses running on the system. I'm not sure if that's a WSL issue or not, but I've never had to be aware of such processes when doing renames in Cygwin or elsewhere.

I built esy with this patch under WSL and ran clean `esy install`s in Dream's [full-stack ReScript](https://github.com/aantron/dream/tree/03e4d37cb5f5f638707479cd46105e2ee2b1df0e/example/w-fullstack-rescript#readme) example, using this script:

```sh
#!/bin/bash

export PATH="/home/antron/code/attic/esy/_build/install/default/bin:$PATH"
export ESY__PREFIX="/home/antron/code/dream/dream/example/w-fullstack-rescript/esy-prefix"
export OCAMLRUNPARAM=b
RUN=1

while true
do
  rm -rf esy-prefix _esy esy.lock lib node_modules/ package-lock.json
  echo
  echo "RUN $RUN"
  which esy
  esy install # --verbosity debug
  if [ $? != 0 ]
  then
    exit
  fi
  RUN=$((RUN+1))
done
```

The example was checked out into NTFS. The system was freshly restarted, and VSCode (or anything similar) was not running.

I used a version of this patch with a print showing the number of attempts before `rename` succeeds, and got the following results from 5 runs:

```
1 attempt:   802
2 attempts:   52
3 attempts:   12
4 attempts:    3
5 attempts:    1
total:       870
```

Based on this, I naively estimated that if a `rename` needs more than 1 attempt, the number of attempts needed decays by a factor of 4 at each step. I set the limit on the number of attempts naively to 8, thus expecting one failure in about 500 `esy install` attempts of the Dream ReScript example, under all these simplified assumptions.

The delay between attempts is (over) one second, so this means that upon legitimate `EACCES`, users will have to wait eight seconds to get an error message. I think there are two ways to address this:

- Fall back to recursive copy rather than retrying `rename` when `rename` fails. Do we have a recursive copy available in esy or its dependencies? Is it fine to leave the source directory intact?
- Detect WSL and retry only on WSL. Waiting for 8 seconds is still a much better user experience than failure to install at all, so the PR will still be an improvement, without, in this case, harming Linux or Mac users. We could also add a message, shown in case we finally fail with `EACCES` on WSL, giving users a hint about potential VSCode or other watchers, and what else they can try to solve the problem.

Closes #1363.
Probably fixes #1097, some of the reports after the first one.
Probably fixes #1083.
Probably fixes #593, but I haven't looked into non-WSL Windows yet.
Probably fixes aantron/dream#63.

cc @bryphe, @rizo, @jordwalke, @iMplode-nZ, @a-c-sreedhar-reddy, @srirajshukla, @andreypopp
@aantron
Copy link
Owner

aantron commented Apr 27, 2023

I'm going to close this as likely fixed by esy/esy#1386.

@aantron aantron closed this as completed Apr 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants