Net::SCP::Error: SCP No such file or directory
When I run capistrano-db-tasks using capistrano 3.7.0 to pull my database with 'cap production db:pull --trace' I get the following error;
Net::SCP::Error: SCP did not finish successfully (1): scp: ./db/vinocellar_production_2
016-12-14-104356.sql.bz2: No such file or directory
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-scp-1.2.1/lib/net/scp.rb:3
65:in `block (3 levels) in start_command'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-ssh-3.2.0/lib/net/ssh/conn
ection/channel.rb:607:in `call'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-ssh-3.2.0/lib/net/ssh/conn
ection/channel.rb:607:in `do_close'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-ssh-3.2.0/lib/net/ssh/conn
ection/session.rb:614:in `channel_close'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-ssh-3.2.0/lib/net/ssh/conn
ection/session.rb:479:in `dispatch_incoming_packets'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-ssh-3.2.0/lib/net/ssh/conn
ection/session.rb:225:in `preprocess'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-ssh-3.2.0/lib/net/ssh/conn
ection/session.rb:206:in `process'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-ssh-3.2.0/lib/net/ssh/conn
ection/session.rb:170:in `block in loop'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-ssh-3.2.0/lib/net/ssh/conn
ection/session.rb:170:in `loop'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-ssh-3.2.0/lib/net/ssh/conn
ection/session.rb:170:in `loop'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-ssh-3.2.0/lib/net/ssh/conn
ection/channel.rb:269:in `wait'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/net-scp-1.2.1/lib/net/scp.rb:3
21:in `download!'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/sshkit-1.11.4/lib/sshkit/backe
nds/netssh.rb:57:in `block in download!'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/sshkit-1.11.4/lib/sshkit/backe
nds/connection_pool.rb:61:in `with'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/sshkit-1.11.4/lib/sshkit/backe
nds/netssh.rb:155:in `with_ssh'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/sshkit-1.11.4/lib/sshkit/backe
nds/netssh.rb:56:in `download!'
/home/map7/code/capistrano-db-tasks-master/lib/capistrano-db-tasks/database.rb:125:in `
download'
/home/map7/code/capistrano-db-tasks-master/lib/capistrano-db-tasks/database.rb:212:in `
remote_to_local'
/home/map7/code/capistrano-db-tasks-master/lib/capistrano-db-tasks/dbtasks.rb:41:in `bl
ock (4 levels) in <top (required)>'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/sshkit-1.11.4/lib/sshkit/backe
nds/abstract.rb:29:in `instance_exec'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/sshkit-1.11.4/lib/sshkit/backe
nds/abstract.rb:29:in `run'
/usr/local/rbenv/versions/2.2.5/lib/ruby/gems/2.2.0/gems/sshkit-1.11.4/lib/sshkit/runne
rs/parallel.rb:12:in `block (2 levels) in execute'
Tasks: TOP => db:pull => db:local:sync
The work around is to set my db_dump_dir to "/tmp" instead of "./db" as it cannot find this. I would assume that this ./db directory should be relative to my Rails.root path on the production server but it doesn't seem to be working.
Still broken in 0.6
Just wanted to let you know that i had the same issue. Didn't look further in it as the workaround with the tmp directory worked fine.
It worked fine by specifying the entire path:
# deploy.rb
set :db_dump_dir, -> { File.join(current_path, 'db') }
@map7 do you have _APP_PATH_/db directory?
@itolosa can you check this branch https://github.com/numbata/capistrano-db-tasks/tree/issues/104/db_dump_dir_fix ?
@numbata I think the error here is to assume that ./ always points to the project directory, and I think is rancid to replace ./ to the current_path. Maybe a Readme update would be great to avoid more confusions
This even doesn't seem a problem due to a change in THIS repository. I upgraded some unrelated gems in the bundle when I suddenly got this error. I wasn't able to restore the previous behavior because I only discovered this problem later in development. But at least reverting capistrano itself to the last known working version didn't help, neither did reverting sshkit, net-scp, or capistrano-db-tasks fix the problem. So something else must have changed behavior.
But the problem is probably still within THIS repo as it depends on some non-defined defaults when it shouldn't (e.g., the working directory).