2010/1/4 Darin Petkov <[email protected]> > > > 2010/1/4 Martin Bligh <[email protected]> > > >> Couldn't we at least have some kind of message at the DEBUG level? I >> >> suppose it's not strictly necessary since we can tell that rsync is >> failing >> >> because scp is being used, but it would be useful to at least at the >> DEBUG >> >> level get some kind of detail from the CmdError. >> >> Maybe this hints at a bigger problem; we shouldn't be wasting time >> trying >> >> to use rsync on systems where it's not available at all. On systems >> where >> >> rsync is available we really do want the verbose messages when it >> fails; on >> >> systems were it's not, we really shouldn't even be running it at all. >> > >> > I was planning to implement this by adding a global config parameter to >> > enable/disable rsync. >> >> Would be nice to make this automatic, rather than a server-side manual >> configurable. (1) it's less stuff to twiddle with (2) it allows some >> clients to >> use rsync, and some not. >> >> If we did an operation up front that we know should succeed, or do some >> other small test for rsync, and that fails, then we can just turn off >> rsync >> for that machine object from then on? >> > > We could check if rsync is executable on the client the first time somebody > tries to get_file/send_file in abstract_ssh. If it's not executable, issue a > DEBUG level message and don't try it anymore. If it's executable, keep > trying rsync for every transfer (and issue a DEBUG level message if it > fails). >
Or as part of AbstractSSHHost._initialize. Darin > > Darin > > >
_______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
