rsync not terminating [#1783330]

Hi,
I'm trying to get drush syncronisation with my hosting plan. I've already installed drush on both local and remote and made some test. Settings aliases, not completely, but for testing purposes. Drush @local status and @remote status works.

But when I start rsync, I get this:

You will destroy data from user@www.mysite.com:/home2/user/www/test3/drupal-7.15/ and replace with data from /volumes/d/applications/mamp/htdocs/local//
Do you really want to continue? (y/n): y
stdin: is not a tty

then I can see that files are being transfered to remote server. But nothing happens in the end. I dont get my command line back. It seems that the process is never ending.

Any ideas???

Aliases settings:


$aliases['onl'] = array (
  'root' => '/home2/user/www/test3/drupal-7.15',
  'uri' => 'http://test3.mysite.com',
  'remote-host' => 'www.mysite.com',
  'remote-user' => 'user',
  'path-aliases' => 
  array (
    '%drush-script' => '/home2/user/bin/drush/drush',
    'php'=> 'usr/bin/php',
	'%site' => 'sites/default/',
	'%dump' => '/home2/user/.drush/dump/stage.sql',

  ),



);

$aliases['dev'] = array (
  'root' => '/volumes/d/applications/mamp/htdocs/test-entity/',
  'uri' => 'default',
  

'path-aliases' => 
  array (
	'%site' => 'sites/default/',
	'%dump' => '/Users/user/.drush/dump/dev.sql',

  ),



);

Thanks in advance,

Comments

Comment #1

heretic381 CreditAttribution: heretic381 commented 13 September 2012 at 20:51

I've noticed later that rsync stops copying files for some reason, and could not complete. --debug option is not working???

Comment #2

heretic381 CreditAttribution: heretic381 commented 14 September 2012 at 10:11

Ok, found that --debug option comes before rsync. SO it works. With bigger files, I get this error:

rsync: writefd_unbuffered failed to write 16385 bytes [sender]: Broken pipe (32)
rsync: connection unexpectedly closed (36 bytes received so far) [sender]
rsync error: unexplained error (code 255) at /SourceCache/rsync/rsync-40/rsync/io.c(452) [sender=2.6.9]

and the second problem is that sometimes copying process just blocs for some reason, even debug wont give any information.

Some advice, infos about this issue?

Comment #3

greg.1.anderson CreditAttribution: greg.1.anderson commented 14 September 2012 at 23:55

Status:

Active

» Fixed

It is my guess that none of your problems are Drush specific. I don't have an idea about your rsync failures; perhaps the support desk of your isp might help. As for stdin: is not a tty, this can often be generated if you have something in your .bashrc that requires a console, such as mesg y. In many distros, the following is used to short-circuit the parts of .bashrc that are not supposed to run in non-interactive mode:

# If not running interactively, exit
[ -z "$PS1" ] && return

Set your PATH and export critical variables before this line, and put anything that you only expect to need when logging in afterwards.

Comment #4

heretic381 CreditAttribution: heretic381 commented 15 September 2012 at 10:55

Thanks for your reply.
You're right. This is not a drush specific issue. It comes with rsync. I've tested file transfer with rsync and got same erros. Rsync hangs or fails.
Rsync is doing job in copying from local to local, remote to remote, but local to remote is a nightmare.

This bug is reported here:
http://rsync.samba.org/issues.html

Unfortunately, no solution is provided. Googling didn't help.

Is there any alternative using rsync in DRUSH???

Comment #5

greg.1.anderson CreditAttribution: greg.1.anderson commented 15 September 2012 at 15:27

rsync is extremely reliable when the endpoints are reliable. You may do well to switch isps. http://drush.org/resources lists some that come with Drush pre-installed.

Comment #6

heretic381 CreditAttribution: heretic381 commented 15 September 2012 at 22:18

rsync is extremely reliable when the endpoints are reliable.

Maybe. Still, no way on shared plans to control what's happening on remote end.

I've just described what was not working for me.

Yeah, I've already checked that list, but lot of them are quite expensive and when they're not, limited in many ways. Having drush installed isn't a guarante that rsync will work in all situations.

Cheers

Comment #7

greg.1.anderson CreditAttribution: greg.1.anderson commented 15 September 2012 at 22:53

For a very low-cost unmanaged full VPS, I have had good luck with urpad.net. I'm currently using the 'advanced' plan, but have used Drupal on other virtual servers with 512MB RAM. The basic plan might work, but I can't speak to that.

Comment #8

heretic381 CreditAttribution: heretic381 commented 15 September 2012 at 23:24

Some of hosting companies from the list above offer testing accounts and I'm currently testing Webenabled (beta). Rsync works like a charm here :)

Comment #9

heretic381 CreditAttribution: heretic381 commented 15 September 2012 at 23:35

Thanks for suggestions and links. Not sure being ready to dive into sysadmin within VPS labyrinths.
With VPS I should probably spend much more time installing and tweaking servers than building sites. Correct me if I'm wrong.

Comment #10

greg.1.anderson CreditAttribution: greg.1.anderson commented 15 September 2012 at 23:41

Gods, I can't advise you on #9. I always use a VPS, because that's what I have always done. I need to do things you probably don't need to do, and find it fast to configure a new system -- at least the Apache / Drupal parts. You might have a different experience your first time out, though. URPad has web hosting plans, but I have not used them. I am using shared hosting on Dreamhost, and it works with Drush. If you're happy with your test account, though, it's probably safest to stick with what you've already tested.

Comment #11

heretic381 CreditAttribution: heretic381 commented 16 September 2012 at 00:02

Well, on one side I don't like to have limitations, as with shared plans, but on the other, I'm not an expert in sys administration and probably wont have enough time to master all technical aspects of server science. Even if I'm tempted.

Although it's similar to OS installation to some extent, I suppose that there's a lot more to do setting Apache, php.ini etc...?