As I cannot reopen this issue (which properly does not make sense
anyway) have I opened a new Bug #1294201 which explains the issue again
how I still experience it even with duplicity including bug fix provided
for this issue.
--
You received this bug notification because you are a member of
I have the same symptoms, after upgrading (downgrading?) from 12.04 to
13.10. My deja-dup backups to Ubuntu One are failing after 10 to 15
minutes, with the after 5 attempts disconnect message. This is really
annoying after it worked fine under 12.04. (3.11.0-17-generic #31-Ubuntu
SMP Mon Feb 3
I have the exact error described in this bug description even with this
fix included in duplicity.
I am using 13.10 with duplicity 0.6.21-0ubuntu4.1.
Is anyone else still experiencing this error?
--
You received this bug notification because you are a member of Desktop
Packages, which is
** Changed in: duplicity
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to duplicity in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Title:
Backup to Ubuntu one failed, after 5 attempts
** Branch linked: lp:ubuntu/raring-proposed/duplicity
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to duplicity in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Title:
Backup to Ubuntu one failed, after 5 attempts status 400 bad
If you put this file in
/usr/share/pyshared/duplicity/backends/u1backend.py does it work?
I've been dragging my feet on pushing this fix to Ubuntu, sorry. I've
had an unrelated problem that made testing difficult.
** Attachment added: u1backend.py
Try using Back In Time instead of Deja Dup. It works perfectly.
On Sun, May 12, 2013 at 4:45 PM, Jacob Mischka x.mischk...@gmail.comwrote:
For the record, I just now stumbled across this bug report after getting
sick of closing deja-dup when it fails on every single boot. I am still
For the record, I just now stumbled across this bug report after getting
sick of closing deja-dup when it fails on every single boot. I am still
receiving the 400 error. I'm not becoming impatient or anything, simply
reporting that it is affecting another person.
Thank you all.
--
You received
** Changed in: duplicity (Ubuntu)
Importance: Undecided = High
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Title:
Backup to Ubuntu one failed, after 5 attempts status
Hi,
I'm just wondering whether there is any progress on this issue. Unfortunately,
this bug makes the Ubuntu backup system unusable for the affected users,
leaving them without a backup of their data. So I believe this creates a
certain level of pressure of eventually fixing this. Thanks!
--
Hi All,
I fixed this in the Duplicity source code. The next step is to get it
in the Duplicity package and get it through the Stable Release Update
(SRU) process. I'm not sure what the maintainers of Duplicity plans are
on when they are going to get the SRU going, but I imagine they would be
** Also affects: deja-dup
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Title:
Backup to Ubuntu one failed, after 5 attempts
** Changed in: duplicity
Importance: Undecided = Medium
** Changed in: duplicity
Status: In Progress = Fix Committed
** Changed in: duplicity
Milestone: None = 0.6.22
** Changed in: duplicity
Assignee: Christopher Townsend (townsend) = (unassigned)
--
You received this bug
So testing with both of my merge proposals, I will still occasionally
see a '400 Bad Request' error or some other error such as a socket error
or a '502 Bad Gateway'. Most of the time, the retry is successful, but
on a rare occasion, I'm seeing all 5 retries fail which causes the
backup to fail.
My proposed fix wasn't exactly complete. Will link a new branch to fix
that and submit another merge proposal.
** Changed in: duplicity
Status: Fix Committed = In Progress
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup
** Branch linked: lp:~townsend/duplicity/fix-1161599-2
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Title:
Backup to Ubuntu one failed, after 5 attempts status 400 bad
** Changed in: duplicity
Status: In Progress = Fix Committed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Title:
Backup to Ubuntu one failed, after 5 attempts
** Also affects: duplicity
Importance: Undecided
Status: New
** Changed in: duplicity
Status: New = Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Hi Sidnei,
Great work! The file pointer position crossed my mind, but the 400 Bad
Request was throwing me off.
I now see the commit that broke this: http://bazaar.launchpad.net
/~duplicity-team/duplicity/0.6-series/revision/901 in
duplicity/backends/u1backend.py. It went from using a bytearray
** Changed in: duplicity
Status: Confirmed = In Progress
** Changed in: duplicity
Assignee: (unassigned) = Christopher Townsend (townsend)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
** Branch linked: lp:~townsend/duplicity/fix-1161599
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Title:
Backup to Ubuntu one failed, after 5 attempts status 400 bad
I think there are two issues going on here.
The first issue that occurs during or right after a file is uploaded.
The python httplib code does a call to get a response from the server
for the packet sent. It appears there may be a transient error such a
socket timeout or something up with the
It is interesting that I have never seen the problem on 12.04. That
suggests that it is not just a problem on the Ubuntu One server, unless
the error recovery in httlib2 has changed in a way that triggers the
problem on the server. Or perhaps the initial error is caused by a bug
in the client
Hi Colin,
I started noticing this issue on 13.04 around the beginning to middle of
March or so. I have not tried this on 12.04 in some time. Are you able
to do a backup to U1 with 12.04 recently?
What is strange that a retry of the same PUT request gets the '400 Bad
Request' error every time.
Hi Christopher
I use it on two machines, one running 12.04 and one 13.04 and have only seen it
on 13.04. I was not using it on 13.04 prior to 28 March when I reported this
bug so I don't know whether it was present in 13.04 prior to that date.
--
You received this bug notification because you
Hi Colin,
Thanks! Knowing that 12.04 works today is a good data point.
I'm working with the U1 folks to help diagnose this. Hopefully they can
help shed some light on this.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in
We've managed to rule out an application error. Those '400 Bad Request'
are being returned by Apache, so we have great confidence than somehow a
malformed request is being sent, which Apache then rejects.
Here's a breakdown of Status 400 failures from the Apache logs over the
course of ~24h:
Looking at the way that httplib2 catches exceptions, if there's for
example a socket.timeout the conn object is not closed
(https://code.google.com/p/httplib2/source/browse/python2/httplib2/__init__.py#1257)
I suspect that might leave the conn object in a semi-broken state.
Since duplicity
Actually it might be more obvious than it seems.
When the PUT request is done, an open file handle is passed as the
'body' argument to httplib2 request(). Since there was a timeout and
retry, the file handle was read from so the current position in the file
has moved. There's no seek() back to
Confirmed that this fixes the problem. When rewinding the file handle on
retry the subsequent PUT request *does* succeed.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Title:
I'm quite convinced this issue is not anything in Deja Dup, so I'm
setting that bug invalid.
I'm still not really sure what the real issue is. I've done quite a bit
of experimentation and still unable to pin this on duplicity, ssl, or
even the Ubuntu One server. I have gathered a Wireshark
After doing some research, it appears that when an SSLError: The read
operation timed out occurs, the connection is closed. In the code that
handles this, there is a retry loop, but the retry loop does not re-set
up the connection, so I believe this is the source of the Bad Request.
It's not
I've been having this problem in Raring for a few months now. I started
doing some investigating and tried running the same duplicity command
that deja-dup spawns. When I do that, duplicity asks for my Ubuntu One
email address and then password. I'm beginning to think that deja-dup
is not
So after using the duplicity command line mentioned above and then
killing that backup and then running a backup through deja dup, it is
working so far now. It hasn't completed the backup yet, but it has
gotten farther than it had in quite some time.
--
You received this bug notification
Bah, it failed:(
I'm going to let the duplicity backup run and see if it fails anywhere
along the way.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Title:
Backup to
Well, the duplicity only command failed as well with the 400 Bad
Request error, so this seems to either be a problem in duplicity or how
Ubuntu One is handling something. It seems to prompted by a read
operation timeout.
Here is the snippet of duplicity output with the failure:
uploading file
** Also affects: duplicity (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
https://bugs.launchpad.net/bugs/1161599
Title:
Backup to Ubuntu one failed, after 5
I upped the verbosity of the duplicity command, and here is the Python
backtrace of the read operation timeout:
Level 1:duplicity:Backtrace of previous error: Traceback (innermost last):
File /usr/lib/python2.7/dist-packages/duplicity/backends/u1backend.py, line
80, in request
resp,
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: deja-dup (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to deja-dup in Ubuntu.
** Description changed:
- On Raring using deja-dup to backup to Ubuntu one, if the backup includes new
folders and is larger than a few tens of MB then the process apparently hangs
at the start of the upload operation for some tens of minutes and then fails
with a popup Backup Failed. Giving
40 matches
Mail list logo
