"sslerror: The read operation timed out" with S3
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Duplicity |
Fix Released
|
Medium
|
Unassigned |
Bug Description
I'm receiving the same error very often in 0.6.06 (and in all previously used versions). It sometimes requires re-running the backup process up to 5-10 times before it finally works.
Traceback (most recent call last):
File "/usr/bin/
with_
File "/usr/bin/
fn()
File "/usr/bin/
globals.
File "/usr/lib/
in set_values
backend_
File "/usr/lib/
line 213, in list
for k in self.bucket.
File "/usr/lib/
30, in bucket_lister
delimiter=
File "/usr/lib/
get_all_keys
body = response.read()
File "/usr/lib/
return self._read_
File "/usr/lib/
value += self._safe_
File "/usr/lib/
chunk = self.fp.
File "/usr/lib/
s = self._read()
File "/usr/lib/
buf = self._ssl.
sslerror: The read operation timed out
Changed in duplicity: | |
status: | New → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Kenneth Loafman (kenneth-loafman) |
milestone: | none → 0.6.07 |
Changed in duplicity: | |
status: | In Progress → Fix Committed |
assignee: | Kenneth Loafman (kenneth-loafman) → nobody |
Changed in duplicity: | |
status: | Fix Committed → Fix Released |
This was affecting me as well. Once I got to several hundred backups, it would fail very often. I don't understand why boto is timing out on S3 LISTs, but I sure know how to work around it. :)
The attached patch adds retry logic to the LIST requests. I just copied the retry code used in GET and PUT. I wanted to remove the duplication of retry code between all three, but the retry code isn't under test and I didn't want to risk breaking something.