On 11/19/06 10:28 AM, "Bill Wraith" <address@hidden> wrote:
... The errors vary somewhat, but
the basic theme is a backend exception failure which appears to be the
os.system call to scp a file from the repository to local or from local
to
repository.
...However, I then tried backing
up to a server on my LAN, which is 100Mbps and still have frequent
backend
exception errors with scp commands moving a repository file to or from
local
tmp file.
In verify mode, the scp also fails.
Any advice on how to resolve this problem or anyone familiar with
problems
using duplicity on fc5?
By the way, fc5 was recently updated to kernel 2.6.18 with all updates,
duplicity is v4.2 installed from tar.gz.
I added the following hack to backends.py around line 142, and it seemed
to
successfully do a very large verify that has failed consistently in the
past. There was one error message, presumably from a failure that was
retried this time. The hack and the error are listed. Are there
parameters
in sshd_config on the server or ssh_config on the client that would
result
in a more forgiving scp/sftp connection, or are there networking
parameters
that might make the scp/sftp/sshd communication less likely to fail? This
failure may happen only once in verifying or backing up a 6GB file.
def run_command(self, commandline):
"""Run given commandline with logging and error
detection"""
log.Log("Running '%s'" % commandline, 5)
if os.system(commandline):
if os.system(commandline):
raise BackendException("Error running
'%s'"
% commandline)
(In other words, just try one more time - and added similar retry to the
popen method)
The error that showed up once, which was probably what would have failed
the
entire backup before was:
ssh_exchange_identification: Connection closed by remote host
As the scp was redone successfully, the verify on a large directory
(about
6GB) went on to complete successfully and showed no errors.