Fixed: ExecJS RuntimeError and FATAL ERROR: v8::Context::New() when deploying Rails to Shared Hosting

I’ve recently been working on setting up a rails app for a site I’m building for one of my side projects.  While I’ve mostly been working on this in my spare time, I decided that it would be important, to one day be able to deploy it to a larger audience (like friends and family). After trying to get rails set up on my old hosting, and being told that Rails 3 wasn’t supported. I recently moved to Vexxhost. Two things enticed me: 1) they’re Canadian; 2) Their hosting is bloody cheap.

So after moving my PHP sites over, I got to work on deploying my currently simple rails app.  And that’s when I hit a problem.

The Problem

ExecJS::RuntimeError in Home#index

Showing /home/jrstarke/apps/___/releases/20120128224905/app/views/layouts/application.html.erb where line #6 raised:

FATAL ERROR: v8::Context::New() V8 is no longer usable (in /home/jrstarke/apps/___/releases/20120128224905/app/assets/javascripts/charities.js.coffee)

Now if you’re finding yourself  in a similar situation, Stop. Take a breath. You’re not very far.

The reason you are finding this is because Rails is clever. The .erb and .js.coffee files in application are compiled, compressed, and this all happens dynamically. They call this the ‘Asset Pipeline’.

The problem is that if you’re shared hosting is anything like Vexxhost (and I imagine most that use cpanel are), their servers in their shared hosting are based on efficiency.  This compiling of assets dynamically takes time and resources, and really, once you’d deployed it to the server, they don’t usually change much (with the exception of a new version, but then that won’t change much either until the next version).

The Solution

It turns out that the solution isn’t all that hard, in fact, most of it I found through a great article on the Ruby on Rails site about The Asset Pipeline – In Production Environments.

The trick is that you essentially need to turn off the asset pipeline. During the dynamic compilation on the fly of assets into a more static compilation. This will still compile your multiple stylesheets and javascript into single files though.

Without further ado, to the solution.

First you need to go into your config/application.rb and disable the application pipeline. You will look for the following line:

config.assets.enabled = true

and turn it to false

config.assets.enabled = false

Update (thanks Hien)If that doesn’t solve it:  go to your Gemfile and comment out the following 3 lines:

gem 'sass-rails', " ~> 3.1.1"
gem 'coffee-rails', "~> 3.1.1"
gem 'uglifier'

These are all the changes we need to make, but before we can deploy the application, we need to compile the assets, ourselves. This is where you will use the following line.

bundle exec rake assets:precompile

At this point use whatever tool you normally use to deploy your app (in my case, Capistrano). If you’re using Capistrano, don’t forget to commit the new assets that would have just been created in your public/assets folder.

Next you’ll need to log into your cpanel, or whatever actually controls your app, stop and restart it. Even if your deploy tool (like Capistrano) just said it restarted your app, don’t believe it, just restart it. This part caught me for a few hours trying to fix this bug. Even though Capistrano said it restarted the app, it still seemed to hold onto the old gems (sass and coffee) until I actually restarted.

With any luck, try your app now, and if your system is anything like mine, it will have worked.


Skip to comment form

  1. David

    I almost never thank people online but I probably should. What a time-saver you are! My ruby on rails sample application works.

  2. Andrew

    after hours of trying to figure out what went wrong, you sir are a life-saver. This page totally explains it, thanks!

  3. hien

    I just set “config.assets.enabled = false”, but it worked for me.
    So this lines :
    gem ‘sass-rails’, ” ~> 3.1.1″
    gem ‘coffee-rails’, “~> 3.1.1″
    gem ‘uglifier’
    is necessary?

    1. Jamie Starke

      Thanks for the note Hien, I’ve updated the post to reflect that. I think when I was working on this, the hosting company I was using had a misconfigured server, so those three gems didn’t work. It should very well work without needing to comment those out, but if it doesn’t, you may need to. Thanks again!

  4. JohnC

    Just getting started with Rails and fell at this hurdle – until I found your blog post.

    Now I can move on from page 1 of the tutorial!

    Thank you!

  5. Ajmal

    How do u review vexxhost – r they good??? and also can the same steps be sued on other hosting providers..

    1. Jamie Starke

      I have been quite happy with them. Like anyone, there is a little down time here and there, but no major complaints.

      As far as I know, this should be fairly general.

  6. braincomb

    Thanks for this post. Oddly enough there wasn’t much information available on the net about this issue. I started having this issue spontaneously when I needed to precompile assets on my production app. Mind you it wasn’t a runtime error, I was only getting it *during* the precompile process. A lot of the threads suggested it might be a memory issue, even though my “ulimit -v” says unlimited, and my VPS is quite powerful. The only thing that fixed it for me was upgrading the sprockets gem from 2.2.2 to 2.10.0.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>