rsync port is reset when using @parallel #494

Closed
robbyt opened this Issue Dec 7, 2011 · 4 comments

Projects

None yet

2 participants

@robbyt
robbyt commented Dec 7, 2011

When I use rsync_project() in a task that is running under @parellel, I receive the following error:

Bad port 'None'
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(601) [sender=3.0.7]

Fatal error: local() encountered an error (return code 255) while executing 'rsync --delete --exclude ".git" -pthrvz --rsync-path='sudo rsync' --rsh='ssh -p None ' /source/ rterhaar@server:/destination/'

Aborting.

However, running non-parallel works fine.

@bitprophet bitprophet was assigned Dec 7, 2011
@bitprophet
Member

Hm, it's odd that parallel makes this not work, offhand I don't see why it'd cause problems. I'll have to look into it, hopefully it will be reproducible on my end.

Do you have a copy of the fabfile code causing this?


It's possible this is also related to #445 though that makes no mention of the parallel angle. I may tackle both at the same time.

@robbyt
robbyt commented Dec 12, 2011

The fabric code is (admittedly...) pretty complicated. There is a task which instantiates a class(object), which calls a function. I will try to write a simple test to see if I can recreate where the rsync code breaks down.

task => class instance => function => rsync

@robbyt
robbyt commented Dec 19, 2011

Came up with a simple test case that illustrates this problem. The following two tasks will return different values. Both should print '22', however when @parallel is enabled, it prints None.

from fabric.colors import cyan
from fabric.api import *

@task
#@parallel
@roles('webapp')
def tester():
    print cyan(env.port)

vs.

from fabric.colors import cyan
from fabric.api import *

@task
@parallel
@roles('webapp')
def tester():
    print cyan(env.port)
@bitprophet
Member

Thanks; could be that env.port is generally getting unset when parallel mode is enabled (since handing off the tasks to subprocesses involves a "clean" copy of the env, IIRC, which might be a buggy process.) Will look.

@bitprophet bitprophet added a commit that closed this issue Dec 19, 2011
@bitprophet bitprophet Manually cherry-pick bd7d5f3 from master.
Should've gone into 1.3, my mistake.

This should fix #494 in addition to its original intent.
490c32b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment