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
-
Open this file for editing:
/data/_myapp_/shared/config/env.custom
(where myapp is the name of your application). - 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).
-
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 env
file.
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.
I don't know whether this is a common mistake or just me being daft but with Rails 3+ you need to precompile the assets for production.
bundle exec rake assets:precompile --trace in your app/current folder should do the trick.
env.custom does not exist. It's just called env. Should be updated.
Hello Naftali,
The env variables specified by the dashboard are included in the `env.cloud` file while the one's applied via the `custom-env_vars` recipe are included under `env.custom` file.
For stack-v6 the following cookbook could be utilized
https://github.com/engineyard/ey-cookbooks-stable-v6/blob/next-release/custom-cookbooks/env_vars/cookbooks/custom-env_vars/README.md
For stack-v5 the following cookbook could be utilized
https://github.com/engineyard/ey-cookbooks-stable-v5/blob/next-release/custom-cookbooks/env_vars/cookbooks/custom-env_vars/README.md
In case of absense of `env.custom` file, you can create a separate one manually via recipes.
Pasan