DB:pull 127 error

[norcle]

Postgres datebase.

When gem 'capistrano-db-tasks', '0.6', require: false

cap production db:pull error

rails exit status: 127
rails stdout: Nothing written
rails stderr: Nothing written

when gem 'capistrano-db-tasks', '0.4', require: false

it`s work fine.

[Fercell]

I am having the same issue, this is what logs say:

DEBUG [fc953976] Finished in 0.547 seconds with exit status 0 (successful). INFO Loading local database config INFO Loading local database config INFO Loading remote database config DEBUG [3b1a9656] Running if test ! -d /home/ubuntu/current; then echo "Directory does not exist '/home/ubuntu/current'" 1>&2; false; fi as $SERVER$ DEBUG [3b1a9656] Command: if test ! -d /home/ubuntu/current; then echo "Directory does not exist '/home/ubuntu/current'" 1>&2; false; fi DEBUG [3b1a9656] Finished in 0.243 seconds with exit status 0 (successful). DEBUG [61adb49d] Running bundle exec rails runner "puts '__CAPISTRANODB_CONFIG_BEGIN_FLAG__' + ActiveRecord::Base.connection.instance_variable_get(:@config).to_yaml + '__CAPISTRANODB_CONFIG_END_FLAG__'" 2>/dev/null as $SERVER$ DEBUG [61adb49d] Command: cd /home/ubuntu/current && ( export RAILS_ENV="production" ; bundle exec rails runner "puts '__CAPISTRANODB_CONFIG_BEGIN_FLAG__' + ActiveRecord::Base.connection.instance_variable_get(:@config).to_yaml + '__CAPISTRANODB_CONFIG_END_FLAG__'" 2>/dev/null )

[luizamboni]

i m too. Error running command (status=pid 5691 exit 1): /home/luiz/projects/exercicios_resolvidos5/bin/rails runner "puts '__CAPISTRANODB_CONFIG_BEGIN_FLAG__' + ActiveRecord::Base.connection.instance_variable_get(:@config).to_yaml + '__CAPISTRANODB_CONFIG_END_FLAG__'"

ruby: 2.6 rails: 5.1 capistrano-db-tasks: 0.6

database: postgress in another machine

[Znow]

@sgruhier - I get the same error, is there any updates on when this is gonna be fixed?

[impdesigns]

I'm also experiencing the same behavior. db:pull fails unless I force version 0.4.

For me at least, this didn't start happening until I updated to Capistrano 3.8.1. Having said that, I'm not exactly a ruby on rails guru and that might have not a damn thing to do with anything...

[ezuk]

The fix above from @sauliusgrigaitis worked for me. Thank you!

[codered]

Can we merge this into master and create a new release?

I verified that @sauliusgrigaitis fix works.

[codered]

By the way, if you want to use the fix before they merge it into a release, you can do the following:

1. In command prompt type "which rails"
2. Change to the directory using the "cd" command.
3. There is a gem folder. Traverse the folder until you find database.rb. Copy paste the file from the fix into there. This will make it work, however, the solution is temporary.

[smtlaissezfaire]

I don't think the patch above works well, since it doesn't work in cases in which the db config can't easily been taken from database.yml (for instance, when database info is encrypted in secrets, etc).

For me, I ran into this one when using rvm. Rvm wasn't loading with the 'rails' command, so it wasn't found. Strange how it wasn't reporting anything out, though.

This fixed it for me:

set :rvm_map_bins, %w{gem rake ruby bundle rails}

[smtlaissezfaire]

See https://github.com/capistrano/rvm/pull/56

[rystraum]

There are 2 issues here.

1. For those who are using capistrano-rvm, make sure that you've set: set :rvm_map_bins, %w{gem rake ruby bundle rails}

This enables capistrano-db-tasks to run rails runner using the bins provided by RVM.

2. For those who have things in the DB being loaded by Rails before running (eg. application settings saved in the DB, which doesn't exist yet, because you're trying to set-up the DB but you can't setup the DB because cap db:push doesn't work because rails runner doesn't run because of an application setting in the db, which doesn't exist yet...), this commit will fix it naively as it forgoes going through rails runner but instead assumes a config/database.yml being read.

This case will fail for those who have a different setup (e.g. creds in secrets.yml) (as https://github.com/sgruhier/capistrano-db-tasks/issues/113#issuecomment-368615296 points out)