Troubleshoot Deployment

Here are some things to check when troubleshooting your deployment because it failed or is not working as expected.

Topics on this page:

• View the deployment log file
• 500 errors after deploying and the deployment log shows “Please install the mysql2 adapter” error
• Rails 3.1 application not displaying correctly in the staging environment
• Application fails to deploy and the deployment log shows “Malformed or pre bundler–1.0.0 Gemfile.lock”
• Application fails to deploy and the deployment log shows “rake aborted! No Rakefile found”
• Application fails to deploy with a timeout message

View the deployment log file

If there is a problem deploying your application, the best place to look initially is the deployment log file. There are two ways to locate and view your logfile:

• On your Dashboard

  Your Dashboard displays a View Log link next to the deployment status message. Click this link to open the log file in a separate browser window for viewing.

• On your instances

  View your log file by connecting to your instances via SSH. After you are connected to your instance, you can locate the log file in your home directory with a filename like the following: yourapp-deploy.log, where ‘yourapp’ is the name of your application deployed on this instance.

You can view the log using the unix commands cat, more or less.

500 errors after deploying and the deployment log shows "Please install the mysql2 adapter" error

If you see the “Please install the mysql2 adapter” error in the deployment log file, follow these instructions to resolve it: 500 errors after deploying / “Please install the mysql2 adapter.

Rails 3.1 application not displaying correctly in the staging environment

If you deploy to your Rails 3.1 application staging environment and your application looks like it has no CSS applied or is using the wrong JavaScript files (even though you are precompiling assets), then try setting config.assets.digest to true as described here.

Application fails to deploy with this message: "Malformed or pre bundler-1.0.0 Gemfile.lock "

If you are using Bundler 0.9, upgrade to Bundler 1.0 or later. See Action Req’d: Bundler 0.9 is being deprecated on October 3rd 2011.

Application fails to deploy with this message: "rake aborted!"

Symptom

Application fails to deploy and the deployment log shows a message like this:

rake aborted! 
No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb) /usr/lib/ruby/gems/1.8/gems/rake–0.8.3/lib/rake.rb:2343:in `raw_load_rakefile’

Solution

This problem occurs if your application is nested in a subdirectory in git.

Place your Rails root directory at the root level of your git repository. (The Rails root directory is the one that contains the app, config, and public directories.)

Application fails to deploy with a timeout message

Symptom

Application fails to deploy and the deployment log shows a message like this:

ERROR: restarting the old unicorn master (12345) timed out
ERROR: Unicorn has failed to reload properly after 120 seconds
original pid: 12345 - new pid: 16789
+ 7m 07s ~> Finished failing to deploy at Tue Jan 15 11:00:00 2013
+ 7m 07s !> [Relax] Your site is still running old code and nothing destructive has occurred.

When this happens the new code has been uploaded to your application instance, but, because the hot start timed out, the Unicorn workers are still running the older code.

Solution

Most likely this problem can be solved by increasing the "hot_time_max" variable.

To increase the "hot_time_max" variable

1. Open this file for editing: /data/_myapp_/shared/config/env.custom (where myapp is the name of your application).

2. Add the line hot_time_max=N where N is the in quarter seconds; for example:

   hot_time_max=600

   This example sets the timeout for a hot restart to 150 seconds (2.5 minutes).

3. Restart Unicorn so that the customizations take effect:

   /engineyard/bin/app_myapp reload 

Note: The env.custom file is not modified by Chef on the main Chef run, so the file does not need to go into a custom recipe to remain unchanged through Chef runs. However, if you ever plan on adding instances to the cluster that aren't using snapshots, then you'd need to make a new env.custom file; so adding it via a custom Chef recipe is recommended. The env.custom file is always sourced by our Unicorn init script after the env file, so anything set in the env.custom file overrides settings in the envfile.

If moderate increases in the hot_time_max variable do not solve the timeout problem, other action might be required:

• Test the application in a development environment, look to see if the application is requiring unnecessary libraries or files.
• If the instance is under too much load and CPU resources are constrained, you might need to increase the size of the application instance.

If you have feedback or questions about this page, add a comment below. If you need help, submit a ticket with Engine Yard Support.