I updated my application from Rails 3.1.x to 3.2.1. I followed the
update instructions in the Rails Guide which hardly requires any
modifications apart from development mode. On my local machine -
running development mode - the application is running fine using Ruby
1.9.3 with the mysql2 gem.
After deployment with Capistrano to the production server (running
Rvm, Ruby 1.9.2) I get:
*** [err :: server] rake aborted!
*** [err :: server Can’t connect to local MySQL server through socket
‘/tmp/mysql.sock’ (2)
*** [err :: server]
*** [err :: server] Tasks: TOP => environment
*** [err :: server] (See full trace by running task with --trace)
Before the update to Rails 3.2.1 all deployments went allright.
[server] executing command
*** [err :: server] rake aborted!
*** [err :: server Can’t connect to local MySQL server through socket
‘/tmp/mysql.sock’ (2)
*** [err :: server]
*** [err :: server] Tasks: TOP => environment
*** [err :: server] (See full trace by running task with --trace)
Can you check your database.yml?
/tmp/mysql.sock looks like a OSX location… Wondering if you copied
your dev properties to production?
That was my first thought as well so I checked the database.yml on the
server. But what I forgot was that I was strugling with the repository
in my new editor TextMate. So I had to check in all new files with my
old editor thereby including the database.yml file as well… which
should not have happened as it is shared.
So now I got them out of the repository, did a export to check they
are really gone. Checked the shared/config path on the server to see
if they are still there and now on deployment I get this:
Yeah, but it’s there! Refreshed my remote server and it’s still there.
This is my deploy.rb part:
namespace :deploy do
task :start do ; end
task :stop do ; end
task :restart, :roles => :app, :except => { :no_release => true } do
run “#{try_sudo} touch
#{File.join(current_path,‘tmp’,‘restart.txt’)}”
end
after “deploy:update_code”, :link_production_db, ‘dragonfly:symlink’
end
desc “Link database.yml from shared path”
task :link_production_db do
run “ln -nfs #{deploy_to}/#{shared_dir}/config/database.yml
#{release_path}/config/database.yml”
run “ln -nfs #{deploy_to}/#{shared_dir}/config/email.yml
#{release_path}/config/email.yml”
end
And database.yml and email.yml are in /shared/config folder as they
have always been.
But look at the Capistrano output:
triggering after callbacks for `deploy:update_code’
*** [err :: ] rake aborted!
*** [err :: No such file or directory - /var/www/vhosts/server/rails/
releases/20120202180855/config/database.yml
This may not be the symlink, but that the database.yml isn’t deployed,
and needs to be copied manually from an older version on the server,
or from your own machine.
Your situation may differ, but I use capistrano to deploy from the
SCM, so if it’s not there, it’s not going to make it to your server.
Hey, hopefully you figured this out already but I was stuck on this
issue as well, and the solution’s pretty simple. You have to make sure
that the “database.yml” file is in the git or scm tool repository that
you’re using.
I think capistrano is trying to pull the database.yml file from the
repository and not any physical location on the deployment server.
Sometimes when you’re working with people you .gitignore the
database.yml file but just make sure you “git add -f” the database.yml
file then commit and push it. Then try cap deploy/cap deploy:update and
hopefully it works!
On Sun, Feb 12, 2012 at 10:28 PM, Vidal Ekechukwu [email protected]wrote:
Hey, hopefully you figured this out already but I was stuck on this
issue as well, and the solution’s pretty simple. You have to make sure
that the “database.yml” file is in the git or scm tool repository that
you’re using.
I think capistrano is trying to pull the database.yml file from the
repository and not any physical location on the deployment server.
Sometimes when you’re working with people you .gitignore the
database.yml file but just make sure you “git add -f” the database.yml
file then commit and push it.
In general, this does not seem to be the optimal solution. I would not
advise to store the production passwords in the version control system
As Capistrano does it by default, link to files in /shared/config, seems
a lot better for the production passwords.
