Jamie Starke bio photo

Jamie Starke

I develop for my career, but I also develop for fun, and whenever I think it can solve a problem I'm having. This has lead me to create side projects, such as Rental Map and BusTimes, among others.

Consulting Newsletter Email LinkedIn Github Stackoverflow More

Overview

ExecJS::RuntimeError in Home#index

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.

If you found this solution useful, and you’re interested in checking out other articles I write in the future, join my newsletter.