Closed jfrux closed 12 years ago
It means your app is crashing as soon as it starts, and never gets a chance to respond to requests. Try jitsu logs, or join #nodejitsu on freenode IRC. On Nov 22, 2012 1:54 PM, "Joshua Rountree" notifications@github.com wrote:
This is happening to me now. And it sends me an email saying that my app is "crash looping" but I don't understand how I'm suppose to debug this???
mccme-macmini:noname rountrjf$ jitsu deploy info: Welcome to Nodejitsu joshuairl info: jitsu v0.11.3, node v0.8.7 info: It worked if it ends with Nodejitsu ok info: Executing command deploy info: Analyzing application dependencies in server.js warn: Local package version appears to be old warn: The package.json version will be incremented automatically warn: About to write /Users/rountrjf/Sites/noname/package.json data: data: { data: private: true, data: engines: { node: '0.8.x' }, data: author: 'Joshua F. Rountree joshua@swodev.com (http://joshuairl.com/)', data: subdomain: 'joshuairl.bilddit', data: scripts: { start: 'server.js' }, data: dependencies: { data: nodemon: 'latest', data: node-uuid: 'latest', data: jade: 'latest', data: uglify-js: 'latest', data: express-namespace: 'latest', data: node-upload-progress: 'latest', data: request: 'latest', data: passport-twitter: 'latest', data: underscore: 'latest', data: stylus: 'latest', data: async: 'latest', data: connect-mongodb: 'latest', data: mongoose: 'latest', data: passport-local: 'latest', data: gzippo: 'latest', data: passport-google-oauth: 'latest', data: csso: 'latest', data: express-singly: 'latest', data: easyimage: 'latest', data: coffee-script: 'latest', data: passport-facebook: 'latest', data: passport: 'latest', data: formidable: 'latest', data: mincer: 'latest', data: passport-singly: 'latest', data: less: 'latest', data: express: 'latest', data: passport-github: 'latest' data: }, data: name: 'joshuairl.noname', data: description: 'a collaborative diy project guides', data: version: '0.0.1-4' data: } data: prompt: Is this ok?: (yes) info: Creating snapshot 0.0.1-4 info Uploading: [=============================] 100% info: Updating app joshuairl.noname info: Activating snapshot 0.0.1-4 for joshuairl.noname info: Starting app joshuairl.noname info: App joshuairl.noname is now started info: http://joshuairl.bilddit.jit.su on Port 80 info: Nodejitsu ok
— Reply to this email directly or view it on GitHubhttps://github.com/nodejitsu/jitsu/issues/363.
that solved it!
My app deploy ended with Nodejitsu ok, and I even was able to use the app for a while. However, I then come back half an hour later and I got this message. This means that it did NOT crash as soon as it started.
Any ideas?
Here's what I got from jitsu logs:
info: Listing logs for application-name [12/16 14:52:03 GMT-0500] Express server listening on port 3000 [12/16 14:52:45 GMT-0500] Express server listening on port 3000 [12/16 14:53:05 GMT-0500] GET / 200 61ms - 652 [12/16 14:53:06 GMT-0500] GET /stylesheets/style.css 304 4ms [12/16 14:53:06 GMT-0500] GET /game.min.js 200 5ms - 236.79kb [12/16 14:53:06 GMT-0500] GET /media/helvetica30EEE.png 304 1ms [12/16 14:53:06 GMT-0500] GET /media/puck.png 304 0ms [12/16 14:53:07 GMT-0500] GET /media/helvetica60000.png 200 2ms - 57.76kb [12/16 14:53:07 GMT-0500] GET /media/helvetica32000.png 304 1ms [12/16 14:53:07 GMT-0500] GET /media/helvetica24000.png 304 6ms [12/16 14:53:07 GMT-0500] GET /media/tileset.png 304 0ms [12/16 14:53:07 GMT-0500] GET /media/helvetica64EEE.png 304 1ms [12/16 14:53:08 GMT-0500] GET /media/pause.png 304 1ms [12/16 16:31:27 GMT-0500] Express server listening on port 3000 [12/16 18:05:22 GMT-0500] Express server listening on port 3000 [12/16 18:05:34 GMT-0500] GET / 200 64ms - 652 [12/16 18:05:34 GMT-0500] GET /stylesheets/style.css 304 4ms [12/16 18:05:34 GMT-0500] GET /game.min.js 200 4ms - 237.18kb [12/16 18:05:35 GMT-0500] GET /media/helvetica30EEE.png 304 1ms [12/16 18:05:35 GMT-0500] GET /media/puck.png 304 1ms [12/16 18:05:35 GMT-0500] GET /media/helvetica32000.png 304 1ms [12/16 18:05:35 GMT-0500] GET /media/helvetica60000.png 304 0ms [12/16 18:05:35 GMT-0500] GET /media/helvetica64EEE.png 304 0ms [12/16 18:05:35 GMT-0500] GET /media/tileset.png 304 2ms [12/16 18:05:35 GMT-0500] GET /media/helvetica24000.png 304 3ms [12/16 18:05:37 GMT-0500] GET /media/pause.png 304 0ms [12/16 18:12:23 GMT-0500] Express server listening on port 3000 [12/16 18:12:29 GMT-0500] GET / 200 66ms - 652 [12/16 18:12:30 GMT-0500] GET /stylesheets/style.css 304 5ms [12/16 18:12:30 GMT-0500] GET /game.min.js 200 6ms - 237.1kb [12/16 18:12:31 GMT-0500] GET /media/helvetica30EEE.png 304 1ms [12/16 18:12:31 GMT-0500] GET /media/puck.png 304 1ms [12/16 18:12:31 GMT-0500] GET /media/helvetica32000.png 304 0ms [12/16 18:12:31 GMT-0500] GET /media/helvetica60000.png 304 1ms [12/16 18:12:31 GMT-0500] GET /media/helvetica64EEE.png 304 1ms [12/16 18:12:31 GMT-0500] GET /media/tileset.png 304 3ms [12/16 18:12:31 GMT-0500] GET /media/helvetica24000.png 304 4ms [12/16 18:12:33 GMT-0500] GET /media/pause.png 304 1ms info: Nodejitsu ok
Please check #266 for more insight! Let know if that helps!
What I get from #266 is that this error can occur for a large variety of reasons, some caused by bugs in application code and some caused by failures in the nodejitsu system, and the only way to tell the difference is to personally ask a nodejitsu admin. I hope I'm reading it wrong.
This is a nodejs core error. If you understand how it works you can easily understand there's a variety of reasons why this can happen — just like a 500 page in any other website.
That said, we work very hard to identify all the possibilities where this can happen and try to return more meaningful reasons but this is not always possible. Just last week we hit a regression in Nodejs core and had to fix it. This happens to use cause we runs thousands of applications, so our balancers and api are widely used in many different ways and we normally hit regressions in code before everyone else. This is a good thing, it means our platform fixes bugs you probably wouldn't know you had until you hit them (at a potentially bad time). Also it's unlikely most of our users have the breath of experience in core that allows them to identify and fix a problem like this in such short notice.
However it's not possible to detect this in users applications, since we do not control your code (and this might mean your code died our on an exception while fulfilling your request — you are possibly doing this in a cycle too!). About 99.99% of the times this error means something is wrong on the user side. And if you deploy your app without nodejitsu you will get the same issue! (if the environment was the same)
I hope I am reading it wrong.
You are not "reading it wrong", but you might be making assumptions about the whole system works that are probably not true. It doesn't say check with an admin, checking your logs should be the first thing you do. Always. We do have dedicated support 24/7 on irc and whenever we do find a bug like this that is our fault we normally fix it within a day (and this is rare).
@AvianFlu first response to this issue said:
Try jitsu logs, or join #nodejitsu on freenode IRC.
Our load balancers are written in Node, and that's why they have errors that some time get proxied directly from core errors. We could make them pretty, but that would have a natural penalty in terms of performance, and it wouldn't fix the errors (just give you a nicer output like "Oops, seems like your code threw an exception! Check out your logs in jitsu with command foo bar"). But you can find out this by reading this issue too.
Hope this helps understand a little better, we appreciate your feedback and hope the issue got fixed by now!
I understand how frustrating this can be, no one likes to have issues deploying. We hate it too, we want you to have the best experience possible using our platform. But always check logs and IRC first. If you have any more suggestion and how we can improve, let us know. We take your feedback very seriously!
Thanks!
ah, the wording "our logs" implied to me a separation between my logs and the logs that y'all are able to access. That, combined with a complete absence of problems on my logs, led to the confusion.
Since this is the first google result (at least it was for me), hopefully others can benefit from more clear explanation you've given here.
Thanks @jeffreybiles, that's partly also why I gave such a detailed information on the problem — it's important for us that people understand what this can mean and how to get it checked and fixed. Let us know if we can help further!
This is happening to me now. And it sends me an email saying that my app is "crash looping" but I don't understand how I'm suppose to debug this???