Several people have asked fairly similar questions to this, so I'm sorry to repeat 'old questions' but I'm completely stuck atm. I'll try to make it as clear as possible what the problem is:
I have a rails app that works locally.
I am using capistrano to try to deploy it on an ubuntu EC2 instance.
After wading through previous problems, I'm coming up against this when running the
'cap deploy' command
(I removed the ec2 server name):
executing "cd -- /u/apps/tweet_app/releases/20130628110910 && bundle exec rake
RAILS_ENV=production RAILS_GROUPS=assets assets:precompile"
servers: ["ec2 server name"]
[ec2 server name] executing command
[out :: ec2 server name] rake aborted!
[out :: ec2 server name]
/u/apps/twitter_app/releases/20130628110910/config/routes.rb:8: syntax error, unexpected ':', expecting kEND
** [out :: ec2 server name] resources :sessions, only: [:new, :create, :destroy]
** [out :: ec2 server name] ^
** [out :: ec2 server name]
/u/apps/tweet_app/releases/20130628110910/config/routes.rb:9: syntax error, unexpected ':', expecting kEND
** [out :: ec2 server name] resources :annotations, only: [:create]
** [out :: ec2 server name] ^
** [ec2 server name]
etc...
Previously, I had an error in my config/initializers/session_store.rb which related to an issue between differences in ruby 1.8.7 and 1.9.2. I was able to resolve it by changing the syntax for hashes. To get to the root of the problem I tried to install ruby 1.9.2 (I also tried 1.9.3) on the ubuntu instance. 1.9.2 is apparently running -
ubuntu#ip-address:~$ ruby --version
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]
But the error still doesn't seem to resolve. It feels like it is still trying to use 1.8.7, which would account for the syntax errors. Other things I have tried include
1. Using rvm to install ruby 1.9.2 on ubuntu (after getting nowhere with a standard install)
2. Using a .rvmrc file to specify that 1.9.2 should be used with the app
Any ideas/suggestions?
Related
I'm deploying to a VPS using capistrano, based on the guide at RailsCasts.
http://railscasts.com/episodes/335-deploying-to-a-vps?view=asciicast
It's failing on the deploy:cold command, with a conflict with Ruby. I actually can't see what the problem is, as when I shell into the same user the Ruby version looks correct.
$ cap shell
cap> which ruby
[establishing connection(s) to 192.xxx.xxx.xxx]
** [out :: 192.xxx.xxx.xxx] /home/deployer/.rbenv/shims/ruby
cap> ruby -v
** [out :: 192.xxx.xxx.xxx ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-linux]
This is the error:
command finished in 655ms
* 2013-07-01 16:40:39 executing `bundle:install'
* executing "cd /home/deployer/rails/assay/releases/20130701144038 && bundle install -- gemfile /home/deployer/rails/assay/releases/20130701144038/Gemfile --path /home/deployer/rails/assay/shared/bundle --deployment --quiet --without development test"
servers: ["192.xxx.xxx.xxx"]
[192.xxx.xxx.xxx] executing command
** [out :: 192.xxx.xxx.xxx] rbenv: version `1.9.3' is not installed
command finished in 662ms
*** [deploy:update_code] rolling back
My question is: how can I debug this? When I read the deploy.rb file I can't see where it even references the Ruby version. Pretty frustrating, I am about ready to ftp the repo up, which is not ideal obviously.
Well I finally got to the bottom of the issue - a mismatch between ruby versions use by Capistrano and what was actually on the server.
To debug Capistrano run it like this:
cap deploy:cold -d
That was you can step through the commands and access the temporary directories on the remote server before they are deleted.
I just had similar issue, the reason was .ruby-version file pointing at 1.9.3 (file was generated by rails-composer), while there was 1.9.3-p392 installed via rbenv on remote machine.
Debug info of capistrano can be shown by tail -f log/capistrano.log.
EDIT:
The issue here was that I used RVM on my local machine and rbenv on the server. This is highly not recommended, if you're managing several ruby installation (or upgrading your ruby version but do not want to change the system's) use either RVM or rbenv on all environments!
/EDIT
So I'll start with a bit history:
I'm in the process of upgrading our rails2 website to rails3. Most of the things are working properly by now, except Capistrano's deploy script.
The current setup I have is:
RVM (1.14.1) installed locally
ruby-1.9.3-p194 (set to the project's folder)
Capistrano v2.12.0 (upgraded from 2.6.0, but it doesn't work on 2.6.0 as well) installed as an RVM gem
rvm-capistrano (1.2.2), added to the Gemfile (after doing some reading online and on SO)
rbenv (with ruby 1.9.3p194 used globally) installed on the server
(by now if you see anything that doesn't make sense, please let me know)
Nothing changed in the deploy script, yet when I try to deploy to my testing server (let's call it beta) I get this error:
* executing `deploy:restart'
* executing "cd /home/foo/bar/current && rake RAILS_ENV=beta queue:restart_workers"
servers: ["208.0..."]
[208.0...] executing command
*** [err :: 208.0...] rake aborted!
*** [err :: 208.0...] no such file to load -- bundler/setup
*** [err :: 208.0...] /home/foo/bar/releases/20120630161947/Rakefile:5
*** [err :: 208.0...] (See full trace by running task with --trace)
** [out :: 208.0...] (in /home/foo/bar/releases/20120630161947)
command finished in 1183ms
failed: "sh -c 'cd /home/foo/bar/current && rake RAILS_ENV=beta queue:restart_workers'" on 208.0...
The relevant part on deploy.rb looks like this:
task :restart do
run "cd /home/foo/bar/current && rake RAILS_ENV=#{CAP_ENV} queue:restart_workers"
run "cd /home/foo/bar/current && rake RAILS_ENV=#{CAP_ENV} db:migrate"
run "touch #{deploy_to}/current/tmp/restart.txt"
end
Needless to say, rake RAILS_ENV=beta queue:restart_workers' works perfectly when run manually on the server. Also, the application gets deployed (the code was copied from git, it's just the last part of the deploy fails).
Lastly, the error didn't change since before I installed rvm-capistrano and added to the Gemfile, so I'm not even sure it's related to rvm, I'm just guessing from looking online.
Thanks
In order to work correctly, rbenv must override all the ruby and gem-related executables with the shims it provides.
Usually this is done with a startup script (this is why it works when you login to your server) but Capistrano logs in without shell and thus does not run those scripts.
You must add the following to your deploy.rb :
set :default_environment, {
'PATH' => "$HOME/.rbenv/shims:$HOME/.rbenv/bin:$PATH"
}
and do not use anything rvm related on your server, rbenv and rvm really do not like each other
PS : a little more explanation on this topic : http://henriksjokvist.net/archive/2012/2/deploying-with-rbenv-and-capistrano/
Made a large update last night and my site is currently down. I used cap deploy:rollback with no luck. The error logs aren't telling me much. The last error I saw when trying to deploy was:
** [out :: website.com] You are trying to install in deployment mode after changing
** [out :: website.com] your Gemfile. Run `bundle install` elsewhere and add the
** [out :: website.com] updated Gemfile.lock to version control.
** [out :: website.com]
** [out :: website.com] You have deleted from the Gemfile:
** [out :: website.com] * asset_sync
command finished in 934ms
My cap tail just says the following with no errors:
Migrating to AddSessionsTable (20120722094547)
Migrating to AddSlugToUserProjects (20120723204816)
Migrating to AddSlugIndexToUserProjects (20120723205558)
Migrating to CreateFriendlyIdSlugs (20120723210904)
Migrating to AddNameToUsers (20120723221700)
Migrating to AddSlugToUsers (20120723222456)
Migrating to CreateComments (20120724203252)
Any help?
Run bundle install on your development server, then cap deploy. Another possible solution: add asset_sync back to your Gemfile.
As last resort, you can run cap -d deploy. It will run deployment step-by-step, asking you for continue on each step. Login to production server in separate shell and do some adjustments between steps manually.
It looks like the Gemfile change didn't go well. How it was fixed:
logged into server, there were 6 ruby processes that were taking all available things. This is almost certainly the unicorn processes trying to start and couldn't… killall -9 ruby
cd into the app's current directory
RAILS_ENV=production bundle exec rake assets:precompile
service unicorn_whimseybox start
It looks like (in the unicorn.log), the error was:
E, [2012-07-26T17:27:10.552912 #24818] ERROR -- : uninitialized constant AssetSync (NameError)
I had the same error after converting some Gemfile source lines into blocks.
The error was due an old Bundler version on production (1.7.3) vs 1.8.3 on development.
I'm new to Capistrano and having trouble debugging an error. Searching suggests this error could be an environment issue of picking up the wrong version of ruby (it's almost certainly not the referenced file as it works fine in test). Using a Capistrano task to dump the ruby version everything looks fine. Running the commands directly on the server works fine, too. I'm using rbenv on the server.
The error:
* executing `deploy:assets:precompile'
* executing "cd /home/deployer/apps/happenate/releases/20120424002545 && bundle exec rake RAILS_ENV=production RAILS_GROUPS=assets assets:precompile"
servers: ["happenate.com"]
[happenate.com] executing command
** [out :: happenate.com] rake aborted!
** [out :: happenate.com] /home/deployer/apps/happenate/releases/20120424002545/config/initializers/session_store.rb:3: syntax error, unexpected ':', expecting $end
** [out :: happenate.com] ...sion_store :cookie_store, key: '_happenate_session'
** [out :: happenate.com] ^
Definitely some sort of ruby environment issue. After cleaning everything up with a proper rbenv environment, the error is gone.
when I run the rake db:migrate I get this
Invoke db:migrate (first_time)
** Invoke environment (first_time)
** Execute environment
rake aborted!
session_store.rb:3: syntax error, unexpected ':', expecting $end
...sion_store :cookie_store, key:
Now I'm running it on a fresh ubutu box.
$ rails -v = Rails 3.1.3
$ ruby -v = ruby 1.9.2p290 (2011-07-09 revision 32553) [i686-linux]
The file I get error on contains some comments and this line of code
Edm2::Application.config.session_store :cookie_store, key: '_edm2_session'
Notes...
I'm not calling $ sudo rake db:migrate. so the like questions up here doesn't have the answer.
what I've read indicates that the hash is wrong, and putting in the old one seems to stop the bleeding.. But I don't want a hymopheliactic application where I am stopping the bleeding all over. I'd rather know what's causing the issue and fix it at the source.
It might help the "helpers" to mention that if I call $rails new demo the file session_store has a different format.. it seems to use the old hash markings... this might be a clue to some, but it is just a pointer to this newb