Here is the command I'm giving to deploy my code to a server.
$ cap production deploy:migrations
* executing `production'
triggering start callbacks for `deploy:migrations'
* executing `multistage:ensure'
* executing `deploy:migrations'
* executing `deploy:update_code'
triggering before callbacks for `deploy:update_code'
* executing `dj:stop'
* executing "RAILS_ENV=production god stop dj"
servers: ["xyz.com"]
connection failed for: xyz.com (ArgumentError: non-absolute home)
I am able to ssh into xyz.com. My capistrano version is
$ cap --version
Capistrano v2.5.19
And it is dependant on net-ssh-2.1.3. The ruby version is ruby 1.9.2p290
Read through similar questions in Stackoverflow, all seem to are suggesting a check on /etc/passwd file in the server. I checked the file and ENV['HOME'] is correctly set for the ssh user.
HOME variable in Server.
$ echo $HOME
/home/deploy
HOME has always been like this from the start. Why would it fail all of a sudden.
Anyone facing the same issue?
Related
In a capistrano deploy of a Ruby-on-Rails project the deployment fails and aborts with a fatal error. The message is
A branch named 'deploy' already exists.
Of course the branch already exists, because we are trying to deploy that branch. Any idea what goes wrong? This is the log, we are using Git, the capistrano branch is set to deploy, the capistrano version is 2.15.9, ruby version is 2.3.1
$ cap staging deploy
triggering load callbacks
* 2016-09-13 12:12:38 executing `staging'
triggering start callbacks for `deploy'
* 2016-09-13 12:12:38 executing `multistage:ensure'
* 2016-09-13 12:12:38 executing `deploy'
* 2016-09-13 12:12:38 executing `deploy:update'
** transaction: start
* 2016-09-13 12:12:38 executing `deploy:update_code'
executing locally: "git ls-remote git#git.my-company.com:developer-group/my-site.git deploy"
command finished in 615ms
* executing "git clone -q -b deploy --depth 1 git#git.my-company.com:developer-group/my-site.git /home/my-user/sites/my-domain.de/releases/20160913101239 && cd /home/my-user/sites/my-domain.de/releases/20160913101239 && git checkout -q -b deploy fe7bd80727d9cce1a275a531c6e21b84e15ab0cd && rm -Rf /home/my-user/sites/my-domain.de/releases/20160913101239/.git && (echo fe7bd80727d9cce1a275a531c6e21b84e15ab0cd > /home/my-user/sites/my-domain.de/releases/20160913101239/REVISION)"
servers: ["my-server"]
[my-server] executing command
** [my-server :: err] fatal: A branch named 'deploy' already exists.
command finished in 2481ms
The command that fails is git checkout -q -b deploy sha_value.
It turns out deploy is a reserved name for Capistrano, so you are not allowed to use it as a branch name. Capistrano apparently tries to create a temporary "deploy" branch if you deploy a Git project.
https://github.com/capistrano/capistrano/issues/359
In general "deploy", "doctor", and "install" are all reserved names in Capistrano, which are also not allowed as stage names (such as "production" or "staging").
I'm following the instructions of Ryan Bates' Deploy to a VPS Railscast to deploy my app to an ubuntu cloud server on Digital Ocean. After I run cap deploy:cold, a few different commands are executed successfully, but then when it gets to 'executing bundle:install' it stays in 'executing command' mode for a very long time without throwing any kind of error or completing, like this
command finished in 171ms
* 2013-06-27 12:57:07 executing `bundle:install'
* executing "cd /home/michaelj/apps/qbruby2/releases/20130627195707 && bundle install --gemfile /home/michaelj/apps/qbruby2/releases/20130627195707/Gemfile --path /home/michaelj/apps/qbruby2/shared/bundle --deployment --quiet --without development test"
servers: ["192.xxx.xxx.xxx"]
[192.241.129.33] executing command
I looked at some other people's deployments (on Stackoverflow) and saw that this command usually completes in a matter of milliseconds. My whole gemfile has less than 20 gems (i.e. the standard gems plus a few extras), yet deployment has been paused here for more than 20 minutes.
Can you suggest what I might do?
The first step in troubleshooting these issues, is ensuring you can run the commands remotely.
Thankfully, capistrano outputs the commands it's trying to execute. Then you can do copy/paste over to the server.
In my experience, i've seen the ssh server terminating ssh sessions for long running processes. (that is migrations or bundle install for example) For those cases, there are a few options (modifying sshd_config on the server has worked for me)
add these lines to /etc/ssh/sshd_config
ClientAliveInterval 30
ClientAliveCountMax 5
I am using whenever gem my schedule.rb content is
every 2.minutes do runner
"Refinery::Page.update_publishing_date_to_list_in_menu" end
I get this by crontab -l
# Begin Whenever generated tasks for: /home/harssh/Documents/Aptana Studio 3 Workspacwinbox/wineboxnew/config/schedule.rb
0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30,32,34,36,38,40,42,44,46,48,50,52,54,56,58
* * * * /bin/bash -l -c 'cd /home/harssh/Documents/Aptana\ Studio\ 3\ Workspacwinbox/wineboxnew && RAILS_ENV=production bundle exec rake page:publish --silent'
# End Whenever generated tasks for: /home/harssh/Documents/Aptana Studio 3 Workspacwinbox/wineboxnew/config/schedule.rb
This runs well on my ubuntu 10.10
But I get (CRON) error (grandchild #26321 failed with exit status 127) on my debian server
where I am using apache and passenger with rvm using Ruby 1.9.3
If I use script in terminal in debian it also runs properly but automated cron task gives error
I am also faced same problem, Finally I resolved this issue.
Problem 1: Ruby path in script/runner file
ruby path in script/runner file:
#!/usr/local/bin/ruby
You can replace (/usr/local/bin/ruby) with your machine ruby path. You can check ruby path with the following command in your machine:
which ruby
Problem 2: I think your runner don't have execution permission.
You can set execution permission to runner file the following way:
Ruby project path/script> chmod +x ruuner
I am trying to deploy a Rails app via Capistrano but am having problems. The messages that get returned in Terminal are as follows:
victor$ cap deploy
* executing `deploy'
* executing `deploy:update'
** transaction: start
* executing `deploy:update_code'
executing locally: "git ls-remote git#github.com:victory/PUM.git HEAD"
/Library/Ruby/Gems/1.8/gems/capistrano-2.5.19/lib/capistrano/recipes/deploy.rb:98: warning: Insecure world writable dir /usr/local/bin in PATH, mode 040777
/Library/Ruby/Gems/1.8/gems/capistrano-2.5.19/lib/capistrano/recipes/deploy.rb:98: command not found: git ls-remote git#github.com:victory/PUM.git HEAD
*** [deploy:update_code] rolling back
* executing "rm -rf /passenger/nginx/pumpl/releases/20101020025555; true"
servers: ["188.126.236.269"]
Password:
I tried to do a Google search but am having a bit of trouble finding a good answer
Would seem your remote installation lacks git.
Have you tried doing a
cap deploy:check
To check the environment and a
cap deploy:setup
To setup the required files?
I finally figured it out.
I just switched to a new Mac that didn't have Xcode installed. This is why Macports was not working correctly. I installed Xcode and after that, I am now able to deploy just fine.
My custom capistrano task "app:sample" fails with the following error message:
mnylen ilmo-on-rails $ cap app:sample
* executing `app:sample'
* executing "export RAILS_ENV=production; cd /home/mnylen/ilmo-on-rails/current; ruby script/coursegen 10"
servers: ["rails.cs.helsinki.fi"]
* establishing connection to gateway `melkinpaasi.cs.helsinki.fi'
* Creating gateway using melkinpaasi.cs.helsinki.fi
* establishing connection to `rails.cs.helsinki.fi' via gateway
Password:
[rails.cs.helsinki.fi] executing command
*** [err :: rails.cs.helsinki.fi] Rails requires RubyGems >= 1.3.2. Please install RubyGems and try again: http://rubygems.rubyforge.org
command finished
failed: "sh -c 'export RAILS_ENV=production; cd /home/mnylen/ilmo-on-rails/current; ruby script/coursegen 10'" on rails.cs.helsinki.fi
Am I missing something or doing something wrong? The task is:
namespace :app do
desc "Run sample data on production2
task :sample do
run "export RAILS_ENV=production; cd #{current_path}; ruby script/coursegen 10"
end
end
If I run the same command from the actual server, it works fine.
Cap is running the remote command as an unexpected user - and that user does not have the correct path to ruby and gem. Check your settings in your recipe for :user and :use_sudo. Carefully read the cap output to see what user is being connected. I see you are using a :gateway; there can be two users in this case. One to connect to the gateway, and another to actually run commands on the target server.
Okay, solved.
The problem was that there was two Ruby installations on the production server.
The .profile file under my home directory on the production server set the PATH environment variable to point to the correct Ruby version.
run command, it seems, doesn't source the .profile file and thus, running ruby script/coursegen 10 in the task used the wrong Ruby version, which was the reason for the weird error message about RubyGems version. This also explains why it worked when manually running the command from production servers shell.
My solution was to use full path to the Ruby executable in my run task, like this:
run "export RAILS_ENV=production; cd #{current_path}; /opt/ruby-enterprise-1.8.7-2009.10/bin/ruby script/coursegen 10"
Of course, this isn't pretty, but it works. If anyone has any prettier solutions, I'd be more than glad to use those instead. :)
Seems like you should update your RubyGems on the remote server.