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

[1.4.x] ENOENT No such file or directory, open ... tmp ... /os.json #7806

Closed
hexsprite opened this Issue Sep 22, 2016 · 64 comments

Comments

@hexsprite
Contributor

hexsprite commented Sep 22, 2016

There is a workaround in this comment below!


Please do not post here with the same issue unless your error message matches exactly as described below. Your error should start with:

Error: ENOENT: no such file or directory, open

and end with:

os.json

If this does not match your error, please search for another, more appropriate issue, or open a new issue as described in reporting a bug


$ meteor list
/Users/jbb/.meteor/packages/meteor-tool/.1.4.1_1.1h0re2h++os.osx.x86_64+web.browser+web.cordova/mt-os.osx.x86_64/isopackets/ddp/npm/node_modules/meteor/promise/node_modules/meteor-promise/promise_server.js:165
      throw error;
      ^

Error: ENOENT: no such file or directory, open '/private/var/folders/q5/2qtj1b5n67b_q7czgc5mj8fh0000gn/T/mt-hdf57l/os.json'
    at Error (native)

I suspect it might have something to do with how many files somewhere since setting ulimit -n 2048 and trying again works fine.
Edit by @abernix: It is not ulimit related.

This is OSX Yosemite and the default ulimit appears to be 256.

@abernix

This comment has been minimized.

Member

abernix commented Sep 22, 2016

What is the output from ulimit -n when run from a new terminal? (Before you run anything else in it or run ulimit manually).

@hexsprite

This comment has been minimized.

Contributor

hexsprite commented Sep 22, 2016

$ ulimit -a
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-v: address space (kbytes)          unlimited
-l: locked-in-memory size (kbytes)  unlimited
-u: processes                       709
-n: file descriptors                256
@austinkettner

This comment has been minimized.

austinkettner commented Sep 23, 2016

Also experiencing this. Curious to see if there are any leads into a solution?

@abernix

This comment has been minimized.

Member

abernix commented Sep 23, 2016

@hexsprite That is not the command I requested to run. ulimit -n ;)

@austinkettner Please provide the same that I requested above.

@austinkettner

This comment has been minimized.

austinkettner commented Sep 23, 2016

After running ulimit -n I get a response of 256.

Turns out our issue was due to the amount of files Meteor was watching due to recent test coverage additions, as discussed (not meteor specific) here: karma-runner/karma#1979 (comment)

@abernix

This comment has been minimized.

Member

abernix commented Sep 23, 2016

@austinkettner Thanks for the details.

@hexsprite The output from running launchctl limit maxfiles would also be helpful in debugging this.

@hexsprite

This comment has been minimized.

Contributor

hexsprite commented Sep 29, 2016

maxfiles 256 unlimited

@screaser

This comment has been minimized.

screaser commented Sep 29, 2016

Also experiencing this.

ulimit -n gives me: 256

launchctl limit maxfiles gives: maxfiles 256 unlimited

(Happy to provide any other info to help find the cause...)

@abernix abernix changed the title from ENOENT when running meteor 1.4.1.1 to [1.4.1.x] ENOENT No such file or directory, open ... tmp ... /os.json Sep 30, 2016

@bilinkis

This comment has been minimized.

bilinkis commented Sep 30, 2016

Having the same issue. Already tried re-installing meteor and that didn't solve the issue.

@bilinkis

This comment has been minimized.

bilinkis commented Sep 30, 2016

+1

@abernix abernix changed the title from [1.4.1.x] ENOENT No such file or directory, open ... tmp ... /os.json to [1.4.1.x][mac] ENOENT No such file or directory, open ... tmp ... /os.json Sep 30, 2016

@abernix

This comment has been minimized.

Member

abernix commented Sep 30, 2016

@Raincal @allanesquina @matthewstewart this sounds like your issue. If you're arriving at this issue, please provide the output of the following to help debug (you too @bilinkis):

  • ulimit -n
  • launchctl limit maxfiles (if you're on Mac).

Then, as a potential solution, please try raising your system user limits by following these instructions: (Make sure you reboot!!!)

Presumably, this is because you're being prevented from opening additional file handles. Apple, for example, sets an absurdly low maxfiles parameter by default (256).

@bilinkis

This comment has been minimized.

bilinkis commented Sep 30, 2016

Oh, I didn't notice the original thread was a mac issue. I'm using ubuntu 16.10, but this are the output for those commands. ulimit -n: 1024. I just noticed that launchctl doesn't actually exist on ubuntu.

@abernix abernix changed the title from [1.4.1.x][mac] ENOENT No such file or directory, open ... tmp ... /os.json to [1.4.1.x] ENOENT No such file or directory, open ... tmp ... /os.json Sep 30, 2016

@abernix

This comment has been minimized.

Member

abernix commented Sep 30, 2016

Honestly, maybe it's not a Mac-only issue, but I had only observed Mac users with the problem. And yes, launchctl is a Mac-only thing.

On Ubuntu you'll need to do something different. I've updated the above instructions.

@bilinkis

This comment has been minimized.

bilinkis commented Sep 30, 2016

Just followed the instructions, and the ulimit has been increased to 64000, although i'm stil, getting the same error 😢 Any other idea?

@abernix

This comment has been minimized.

Member

abernix commented Sep 30, 2016

@bilinkis Not currently. TBH, I really didn't expect it to be an issue with file limits but I was going with the original report. Can you provide more details about the problem? Did this happen on previous versions of Meteor?  Does this happen to you on a new Meteor project, or only an existing one? Anything you could provide to me so I can reproduce it locally?

@bilinkis

This comment has been minimized.

bilinkis commented Sep 30, 2016

I'm running Meteor 1.4.0.1 and i'm using an existing project. It worked until I deleted the .meteor folder to rebuild my project. After that it stopped working. Hope that helps and i'm available to provide any more information you could need. Thanks m8!

@abernix

This comment has been minimized.

Member

abernix commented Sep 30, 2016

@bilinkis Can you reproduce it in a new project? If so, can you post the project to GitHub and share it?

@screaser

This comment has been minimized.

screaser commented Sep 30, 2016

Just in case this helps; in my case I have an existing Meteor app with dev instances on two different Macs.

On the Mac running OS 10.12 (production) things continue to work fine. On the Mac that I upgraded to 10.12.1 (public beta 2) this problem occurs.

I can't say for certain that the problem started exactly when I upgraded as I wasn't using that dev machine very frequently at the time.

@bilinkis

This comment has been minimized.

bilinkis commented Sep 30, 2016

just tried to create a new project using meteor create and I still get the same error. Just re-installed nodejs and npm just in case, but still happening.

@abernix

This comment has been minimized.

Member

abernix commented Sep 30, 2016

@bilinkis Can you tar.gz up the new project and send it to me? (via Dropbox maybe?, but anything is fine – it could be large). node and npm shouldn't affect it.

tar cvf - meteor_project_dir | gzip -9c > for_abernix.tar.gz
@jakobrosenberg

This comment has been minimized.

jakobrosenberg commented Oct 19, 2016

Also getting this error for 1.4.2-rc.0 on Windows 10 x64

@abernix

This comment has been minimized.

Member

abernix commented Oct 19, 2016

@jakobrosenberg Please use the workaround for Windows users over here

@raix Based on the update in the 1.4.2 issue, I believe you got this fixed after you posted this using the work-around I suggested above so will assume you're okay now.

abernix added a commit to abernix/meteord that referenced this issue Oct 19, 2016

Add METEOR_WAREHOUSE_URLBASE and --unsafe-perm
In Meteor 1.4.2 `--unsafe-perm` will be required to be passed to `meteor` to run Meteor as root (as `docker` does).

Additionally, the METEOR_WAREHOUSE_URLBASE variable is set here to force usage of the still decent CDN and avoid meteor/meteor#7806.  I hope to remove this asap.
@pashka4281

This comment has been minimized.

pashka4281 commented Oct 19, 2016

same story here. Our test builds stopped working on Semaphore.

/home/runner/.meteor/packages/meteor-tool/.1.4.1_2.354htk++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/meteor-promise/promise_server.js:165
      throw error;
      ^

Error: ENOENT: no such file or directory, open '/tmp/mt-1kweroj/os.json'
    at Error (native)
                                              /home/runner/.nvm/v0.11.16/lib/node_modules/gagarin/lib/mocha/gagarin.js:251
      throw err;
            ^
Error: meteor build exited with code 1
  at ChildProcess.onExit (/home/runner/.nvm/v0.11.16/lib/node_modules/gagarin/lib/meteor/build.js:160:25)
  at ChildProcess.emit (events.js:110:17)
  at Process.ChildProcess._handle.onexit (child_process.js:1067:12)
Semaphore: ~/app $ uname -a
Linux semaphore-1609 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

Note here:
If I do this:

export METEOR_WAREHOUSE_URLBASE=https://d3fm2vapipm3k9.cloudfront.net
(yeah this is probably for windows users only, but still has interesting effect)
and run meteor it stucks forever saying "downloading xxx packages" and never actually finish building project. But them I cancel it, do another export

export METEOR_WAREHOUSE_URLBASE=""

and suddenly it works when I run meteor after that.

If I change order of actions or remove any step => won't build

(app uses Meteor 1.2.1 version)

@theodorDiaconu

This comment has been minimized.

Contributor

theodorDiaconu commented Oct 20, 2016

CONFIRMED SOLUTION provided by @abernix

export METEOR_WAREHOUSE_URLBASE=https://d3fm2vapipm3k9.cloudfront.net
meteor update --release 1.4.2-rc.1
@bilinkis

This comment has been minimized.

bilinkis commented Oct 21, 2016

After crying for several weeks, I finally ran into @abernix 's response, that seems to solve my issue!
Thanks @abernix and everyone else that provided info to get to this workaround

benjamn added a commit that referenced this issue Oct 21, 2016

Report an error when HTTP request body is incomplete.
When a download aborts prematurely, the status code is often 200 OK, even
though we probably should not proceed with any further processing of the
downloaded information.

This silent failure leads to problems like the dreaded "Error: ENOENT: no
such file or directory, open... os.json" (#7806 and others), which were
hard to diagnose properly because the failure occurred only later, when
extracting a buffer that downloaded incompletely.

The getUrlWithResuming helper should be able to retry after this error is
thrown, which will result in a more helpful warning, even if in the most
common case, i.e. MaxCDN failure, it will never actually succeed.

Note that this change will not help until Meteor 1.4.2 is officially
released and becomes the implementation used to download later releases.

Mitigates #7806.
@mjmasn

This comment has been minimized.

Contributor

mjmasn commented Oct 24, 2016

Although judging by the commit 545493b above this is fixed or at least mitigated for 1.4.2 is there not going to be the issue that to get to the working version you need to use the workaround? Probably can't expect every Meteor user to work that out... I may be misunderstanding the issue but it seems that on any type connection here in the UK, updating Meteor fails. I find it hard to believe that the connection is dropping so regularly. Is there an actual behind-the-scenes cause or is it literally just that the new CDN is crap? (and if so why is it being used) Forgive me if I'm missing the point here!

@derwaldgeist

This comment has been minimized.

derwaldgeist commented Oct 24, 2016

@mjmasn Same here in Germany. I am so glad I got help from @hwillson in the Meteor forums who pointed me to this issue thread. Otherwise I would have been completely stuck. If you ask me, this issue has the potential of losing a lot of frustrated Meteor users.

@abernix

This comment has been minimized.

Member

abernix commented Oct 27, 2016

@mjmasn @derwaldgeist Surprisingly, the CDN was actually just behaving poorly – for example, I just straight-up could not wget the entire meteor-tool through the CDN without it (remotely) closing the connection. I used to be able to, and then it just stopped working – for over two weeks.

I don't work for MDG but I will speculate as to the reason for "still using it": The meteor-tool (and all packages throughput combined) likely produce a substantial amount of traffic (read: $$$) and I believe the bandwidth warehouse.meteor.com utilizes is very graciously provided by the CDN provider. I don't think that CloudFront is gracious nor are they the cheapest and I know that the CDN was not failing for everyone, just many folks.

All that being said, I just reached out to MaxCDN Support over chat and worked with their (actually really fantastic support team, especially considering I'm just an end-user) for almost 45 minutes and they reproduced and corrected an issue on their end. For the first time in the last two weeks, I am able to fully download Meteor without using any work-arounds.

I'm sure the situation is not perfect for everyone, but can anyone who was experiencing this problem consistently confirm that this is fixed? With the change that was made in 1.4.2 (30aec9f) to prevent incomplete downloads (and retry them), I really hope to put this issue to rest.

@mjmasn

This comment has been minimized.

Contributor

mjmasn commented Oct 27, 2016

@abernix seems to be working again here in Wales too :) and yeah I did wonder if they had some free arrangement with MaxCDN, CF definitely ain't cheap!

@benjamn

This comment has been minimized.

Member

benjamn commented Nov 1, 2016

Newly published versions of meteor-tool seem to be downloading much more reliably for me. Thanks very much for getting in touch with the CDN support team, @abernix!

@benjamn

This comment has been minimized.

Member

benjamn commented Nov 11, 2016

This still seems to be fixed, thanks primarily to @abernix reaching out to the MaxCDN support team. I'm really glad they found a solution, because it sure is nice not having to pay for bandwidth! 😀

@allanesquina

This comment has been minimized.

allanesquina commented Feb 9, 2017

@abernix After upgrade my connection speed this problem was solved. So it might be a timeout issue or something related to server response.
My connection speed was 2.5mb and now is 4.0mb (yep, too bad, I know 😞).
I hope this information help you guys to have a better idea of what is going on.
Thanks! 👍

@abernix

This comment has been minimized.

Member

abernix commented Feb 10, 2017

Glad you've got it working, @allanesquina.

Generally speaking, newer versions of Meteor (>=1.4.2) will handle this much more gracefully. For specific insight into how this has evolved, see my comment here.

Since this is generally resolved, I'll lock this issue now out of respect for the 20+ eyes watching this thread. If you continue to experience this exact problem, please make sure you're on Meteor 1.4.2 or higher (reinstall using curl https://install.meteor.com/ | sh if necessary) and if that doesn't fix it, please open a new issue!

Thanks to all those involved!

@meteor meteor locked and limited conversation to collaborators Feb 10, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.