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

Meteor 9.1 Failed to receive keepalive! Exiting. => Exited with code: 1 #2536

Closed
ChadMartinson opened this Issue Sep 7, 2014 · 77 comments

Comments

Projects
None yet
@ChadMartinson

ChadMartinson commented Sep 7, 2014

After updating to 9.1 Meteor won't keep running on localhost. It happens on file save when refreshing the client.

@rfox90

This comment has been minimized.

rfox90 commented Sep 7, 2014

Does this occur with a blank newly created app?

@ChadMartinson

This comment has been minimized.

ChadMartinson commented Sep 7, 2014

No it was an update, sorry. After it throws the error code the server restarts.

@rfox90

This comment has been minimized.

rfox90 commented Sep 7, 2014

Can you isolate the problem? Or provide a repo that reproduces it?

@ChadMartinson

This comment has been minimized.

@rfox90

This comment has been minimized.

rfox90 commented Sep 7, 2014

https://github.com/ChadMartinson/buttonstew/blob/master/global.js

Has some weirdly formatted JS.

Its:

thing = function() {
};

Not:

thing = function() {
},

Doing things like this will lead to weird interpretation by meteor and its internals which might be causing the issue.

Is this the file you are editing, that causes the problems?

Parse all javascript through something like http://jshint.com/ in your editor.

@ChadMartinson

This comment has been minimized.

ChadMartinson commented Sep 7, 2014

oh wow, thanks

no that wasn't the file but it fixed it. There must have been a bug up until 9.1 because I started a .8 and never had that happen.

@ChadMartinson

This comment has been minimized.

ChadMartinson commented Sep 7, 2014

Ooops too soon. Nope it is still giving the same code in my server console.

@ChadMartinson

This comment has been minimized.

ChadMartinson commented Sep 8, 2014

I went back to 0.9.0.1 and it is working just fine

@PoBuchi

This comment has been minimized.

PoBuchi commented Sep 8, 2014

I am having the same experience and it also happened on completely newly created empty app as well. this errors goes on both 0.9.1 and 0.9.2

@SkeLLLa

This comment has been minimized.

SkeLLLa commented Sep 8, 2014

I can confirm this too. In my meteor 0.9.1.1 it also happens. In my case it happens when I run my application with --production flag.

@ndemoreau

This comment has been minimized.

ndemoreau commented Sep 8, 2014

Same problem here...

@maz-dev

This comment has been minimized.

maz-dev commented Sep 9, 2014

Same problem here with 0.9.1.1
Works fine with 0.9.0.1
CSS live injection is affected too.

@tanis2000

This comment has been minimized.

tanis2000 commented Sep 9, 2014

Same problem with 0.9.1.1 for an app of mine.

@avital

This comment has been minimized.

Contributor

avital commented Sep 9, 2014

I couldn't reproduce this (tried on both Mac and Linux), and modifying a file with vim, emacs, and directly modifying an app's files.

@ChadMartinson your repo doesn't run for me -- it can't find the npm package.

We'd like to figure this out -- can someone point to an exact reproduction (OS, editor, app repository, ...)

@mizzao

This comment has been minimized.

Contributor

mizzao commented Sep 10, 2014

A similar issue was mentioned in the 0.9 RCs: #2395. In that case, if the bundling or constraint solver in the dev parent process was too slow, the meteor child process would terminate due to not receiving its customary poke (https://github.com/meteor/meteor/blob/devel/packages/webapp/webapp_server.js#L33).

Not sure why it would happen with a blank app, though. Might be just happening on either slow computers or huge apps.

@fabien-h

This comment has been minimized.

fabien-h commented Sep 10, 2014

@ndemoreau

This comment has been minimized.

ndemoreau commented Sep 10, 2014

I have the issue with this code: https://github.com/ndemoreau/immo2

I'm on a mac Mavericks, Webstorm, testing on Chrome

@thinklinux

This comment has been minimized.

thinklinux commented Sep 10, 2014

I have the same issue... Linux Xubuntu 32bit just editing file with sublime 2. But it occurred just once. Can't reproduce it now :/

@fabien-h

This comment has been minimized.

fabien-h commented Sep 10, 2014

It seems to be random for me. Sometimes I Save ten time and have a nice browser reload and CSS injections. Sometimes the server keeps crashing.

@pbeets

This comment has been minimized.

pbeets commented Sep 10, 2014

I'm having the same issue. It takes about 30 seconds from save to the hot reload actually happening. Using v0.9.1.1.

@awatson1978

This comment has been minimized.

Contributor

awatson1978 commented Sep 10, 2014

I just started having this as well. Oddly, it was fine when I upgraded to 0.9.1 on my work computer, but when I synced at home, then I started getting the keep alive errors. Also, I noticed that the number of packages that were flagged for upgrade was different. The keep alive broke on the more restrictive constraint resolver, which was asking for more packages to be updated.

@glasser

This comment has been minimized.

Member

glasser commented Sep 11, 2014

I'm having trouble reproducing, but this clearly is a real issue for our users. Anyone in the Bay Area experiencing this want to stop by MDG with their laptop?

@ChadMartinson

This comment has been minimized.

ChadMartinson commented Sep 11, 2014

I went back to 0.9.0.1 and it was working. I switched from bootstrap to foundation and it was working. I added less and bootstrap less and now 9.0.1 is messing up with same error.

@glasser

This comment has been minimized.

Member

glasser commented Sep 11, 2014

Suspicion: It's not new in 0.9.1. It's just that the new client/CSS refresh feature in 0.9.0 means that we run the bundler (which doesn't yield much) which the app is still running, instead of after killing it.

We should make the bundler yield more. We should also just swap out keepalive for a better mechanism of cleaning up apps.

@tanis2000

This comment has been minimized.

tanis2000 commented Sep 11, 2014

@glasser too bad I live on the other side of the ocean or I'd be there right away :)

I tried removing the bootstrap3 package (nemo64:bootstrap3) and all of my less files and now it's working again and it's not complaining anymore.

The refresh time is still high, though (above 10 seconds).

@maz-dev

This comment has been minimized.

maz-dev commented Sep 11, 2014

Can confirm, it's seems to be related to nemo64:bootstrap package. Could be the less files that are generated in ./client/lib or something with the load order. Sorry, I have no clue.

I'm using sublime text 3 on OSX Maverick.

You can try it with https://github.com/maz-dev/crassier/tree/feature/keepalive, it's just been updated again to 0.9.1.1 and nemo64:bootstrap.

You just have to spawn the meteor server and try to change a less file or some html files. Can reproduce with both.

Edit: on 0.9.1.1 without nemo64:bootstrap it's working perfectly for now.

@ndemoreau

This comment has been minimized.

ndemoreau commented Sep 11, 2014

Hi, I am indeed using this nemo64:bootstrap package as well. @maz-dev do you have an alternative of a package with bootstrap3-less?

Thanks

@tanis2000

This comment has been minimized.

tanis2000 commented Sep 11, 2014

@Nemo64 Marco, maybe you've got some insights of what might be going wrong with that package?

@fpaboim

This comment has been minimized.

fpaboim commented Sep 18, 2014

The hack is working, though it's a bit slow even with the new css injection, still it's certainly more workable then with all the reloads because of the keepalive bug! Thanks for the temporary fix! ps- I get the same problem with ubuntu without virtualization and on an ssd with a good processor using less, so it seems it seems there are two issues: the keepalive bug when bundling takes too long, and the performance problem with less that triggers the former issue.

@ephemer

This comment has been minimized.

ephemer commented Sep 19, 2014

I haven't tried the hack / workaround yet because I was more interested by the fact that the same code doesn't cause issues on different computers.

I found the problem for my team was that we have about 30 LESS files all referencing a global.less for mixins. The problem was that the global.less also contained entries (only about 5, seems like that was enough) that were not mixins (normal css statements). Each of these was being imported 30 times into the compiled CSS output. Once I untangled that mess (taking out the non-mixin CSS, rename to global.import.less), I found that the issue almost never appears now.

@rfox90

This comment has been minimized.

rfox90 commented Sep 19, 2014

Its all about speed. What you've described has simply decreased the build time sufficiently to not show the issue. I would install the hack just in case your servers have a slow day.

@aldeed

This comment has been minimized.

Contributor

aldeed commented Sep 19, 2014

Just to clarify, is HTML refreshing working for anyone? I have the workaround in place, and that prevents the keepalive error. CSS changes are picked up after 8-10 seconds, but changes to HTML files never cause a browser refresh automatically. Never ever. Is that the same thing others are seeing, or do I have a different issue to investigate?

@PoBuchi

This comment has been minimized.

PoBuchi commented Sep 19, 2014

@aldeed well after hack, all works properly, though sometimes slowly, for all our team

@ephemer

This comment has been minimized.

ephemer commented Sep 19, 2014

@rfox90 We don't do any code hotpushes to the server anyway (we always redeploy the complete bundle) - can't see this issue here being problematic in production. Do you do code hotpushes onto a production server? How?

Also, I'm surprised that removing the few non-mixin CSS entries from a file makes such a HUGE difference to compile time. Maybe it gives someone in the CDG a clue as to what the bug is.

@aldeed Changing the HTML code/templates here causes a page refresh (as has been the case since I started using Meteor at version ~ 0.7). The CSS hotpushes also work on my machine, but only when I don't get the keepalive server crashing bug (the issue referenced in this thread).

@aldeed

This comment has been minimized.

Contributor

aldeed commented Sep 19, 2014

OK, thanks. Auto page refreshing stopped working for me around 0.9.0 or 0.9.1, same time the keepalive issues started, so I thought it was the same issue. Guess it's not.

@rfox90

This comment has been minimized.

rfox90 commented Sep 19, 2014

@ephemer I don't have any productions apps. Even though it's dev I still don't want my environment crashing so I added it. I usually end up stressing out dev servers more than production anyway :)

@vjau

This comment has been minimized.

Contributor

vjau commented Sep 19, 2014

AFAIK in production when you are replacing the bundle it does a hot code
push (albeit slowly).

On Fri, Sep 19, 2014 at 3:15 PM, Richard Fox notifications@github.com
wrote:

@ephemer https://github.com/ephemer I don't have any productions apps.
Even though it's dev I still don't want my environment crashing so I added
it. I usually end up stressing out dev servers more than production anyway
:)


Reply to this email directly or view it on GitHub
#2536 (comment).

@rfox90

This comment has been minimized.

rfox90 commented Sep 19, 2014

@vjau That was my understanding too. Fix bug -> pull -> Everyone has the fix with no refreshing :).

In which case yup please install the fix just in case.

@lottamus

This comment has been minimized.

lottamus commented Sep 19, 2014

process.argv = _.without process.argv, '--keepalive'
Meteor.startup -> console.log "LISTENING"

works for us

@ephemer

This comment has been minimized.

ephemer commented Sep 22, 2014

@vjau @rfox90 thanks for the tip about production deployment. I'm not heavily involved with the deployment in our team but I think we do it differently. Maybe it's time to change, especially with the new packaging system (I think that was holding us back from doing it like you suggest - different architectures meant weird things happened on recompile)

estark37 pushed a commit that referenced this issue Sep 24, 2014

Emily Stark
Replace keepalives with a check if the parent pid is still running.
Downsides:
* Doesn't catch the case where the parent is CPU-hogging (but maybe we
  don't want to catch that case anyway, since the bundler not yielding
  is what's causing #2536).
* Could be fooled by pid re-use, i.e. if another process comes up and
  takes the parent process's place before the child process dies.

Untested so far because I haven't been able to actually kill a parent
process in such a way that the child stays alive.

estark37 pushed a commit that referenced this issue Sep 25, 2014

Emily Stark
Replace keepalives with a check if the parent pid is still running.
Downsides:
* Doesn't catch the case where the parent is CPU-hogging (but maybe we
  don't want to catch that case anyway, since the bundler not yielding
  is what's causing #2536).
* Could be fooled by pid re-use, i.e. if another process comes up and
  takes the parent process's place before the child process dies.

Untested so far because I haven't been able to actually kill a parent
process in such a way that the child stays alive.

estark37 pushed a commit that referenced this issue Sep 25, 2014

Emily Stark
Replace keepalives with a check if the parent pid is still running.
Downsides:
* Doesn't catch the case where the parent is CPU-hogging (but maybe we
  don't want to catch that case anyway, since the bundler not yielding
  is what's causing #2536).
* Could be fooled by pid re-use, i.e. if another process comes up and
  takes the parent process's place before the child process dies.

Untested so far because I haven't been able to actually kill a parent
process in such a way that the child stays alive.
@estark37

This comment has been minimized.

Contributor

estark37 commented Sep 25, 2014

This should be fixed on devel now; we replaced keepalives with a different mechanism that is hopefully less brittle (and definitely won't be fooled by long-running bundles). It'll be out in a release in the next week or so.

Thanks for all the help tracking this one down!

@vjau

This comment has been minimized.

Contributor

vjau commented Sep 26, 2014

@estark37 Thank you Emily, but i suppose it doesn't fix the "long-running bundles" which were causing it.
AFAIK this problem is "less" related.

@ChadMartinson

This comment has been minimized.

ChadMartinson commented Sep 28, 2014

The issue is not "less" related. I have switched to vanilla css and am experiencing the same issue.

@estark37

This comment has been minimized.

Contributor

estark37 commented Sep 28, 2014

@vjau: no, it doesn't change the bundler, but instead stops the bundler from interfering with the communication between the top-level runner process and the web server process. Is there another problem that you're seeing that is caused by long-running bundles?

@ChadMartinson: no, I don't believe this problem is less related, but rather related to any CPU-heavy computation that is done during app bundles.

In any case the fix is on devel, so I'm going to go ahead and close this issue. It'll be out in a release soon.

@estark37 estark37 closed this Sep 28, 2014

@ChadMartinson

This comment has been minimized.

ChadMartinson commented Sep 28, 2014

Ok cool thanks

@ndemoreau

This comment has been minimized.

ndemoreau commented Oct 3, 2014

@estark37 : Hi Emily, is this issue supposed to be fixed with 0.9.3.1? I'm running this release but still having the issue. Thx.

@lloydde

This comment has been minimized.

lloydde commented Oct 3, 2014

@ndemoreau no, you can see by the branch and tag info on the commit above that it is slated for 0.9.4.

@choyweston

This comment has been minimized.

Contributor

choyweston commented Oct 3, 2014

+1 (on 0.9.3.1)

@bryankennedy

This comment has been minimized.

bryankennedy commented Oct 3, 2014

I ran meteor update --release METEOR@0.9.4-pre.6 to get the 9.4 pre-release.

This fixes these problems on my app.

@Batistleman

This comment has been minimized.

Batistleman commented Oct 6, 2014

@bryankennedy +1 running 0.9.4-pre.6 fixed it

@angjelo

This comment has been minimized.

angjelo commented Oct 5, 2015

@aldeed about the edit that you were saying for the oldLink is right cause i had the same problem like you . I made some changes in my css file many times in a short time of period and i got the same error. I did a meteor reset and it fixed my problem.

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