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

[ChadMartinson]

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

[rfox90]

Does this occur with a blank newly created app?

[ChadMartinson]

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

[rfox90]

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

[ChadMartinson]

sure
https://github.com/ChadMartinson/buttonstew

[rfox90]

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]

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]

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

[ChadMartinson]

I went back to 0.9.0.1 and it is working just fine

[PoBuchi]

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]

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]

Same problem here...

[monocursive]

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

[tanis2000]

Same problem with 0.9.1.1 for an app of mine.

[avital]

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]

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]

Same here
(and same on stack overflow : http://stackoverflow.com/questions/25545928/hot-load-error-failed-to-receive-keepalive )

[ndemoreau]

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

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

[thinklinux]

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]

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]

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]

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]

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]

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]

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]

@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).

[monocursive]

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]

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]

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

[fpaboim]

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]

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]

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]

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]

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

[ephemer]

@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]

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]

@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]

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]

@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]

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

works for us

[ephemer]

@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]

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]

@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]

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

[estark37]

@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.

[ChadMartinson]

Ok cool thanks

[ndemoreau]

@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.

[dwlf]

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

[choyweston]

+1 (on 0.9.3.1)

[bryankennedy]

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]

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

[angjelo]

@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.