Resuming a failed upload crashes with ValueError: I/O operation on closed file

[Roman Yepishev]

Resuming a failed upload crashes with ValueError: I/O operation on closed file. After this this particular upload is dropped and syncdaemon believes it is synchronized (IDLE)

TEST CASE:
1. Grab a file of substantial size (100Mb is ok) which is not yet on Ubuntu One
2. Put it to ~/Ubuntu One folder
3. Wait until upload starts by looking at u1sdtool --current-transfers
4. Simulate server disconnect/network issue by shutting down network.
5. SD will enter READY state, upload is still queued
6. Connect to network again

Expected results:
SD starts to upload the remaining part of the file

Actual results:
Upload fails completely - AQ_UPLOAD_ERROR, syncdaemon returns to IDLE state. File is not uploaded to personal storage.

2011-10-12 18:08:52,408 - ubuntuone.SyncDaemon.ActionQueue - ERROR - Upload share:'' node:'e7469f58-c4b2-4326-932a-25bb2d4f2d18' Upload(share_id="''", hash="'sha1:580b8902e8e91d9ce038c44d115b67599c5f35ff'", running='False', node_id="'e7469f58-c4b2-4326-932a-25bb2d4f2d18'", upload_id="'2d1927b0-4377-5438-a1bc-811596d4ea58'", crc32='1135887907L', path="'/home/rtg/Ubuntu One/Test/file.ext'", previous_hash="''", size='1453065906') failure: I/O operation on closed file (traceback follows)
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/ubuntuone-client/ubuntuone/syncdaemon/action_queue.py", line 1370, in run
    result = yield self.running_deferred
ValueError: I/O operation on closed file
2011-10-12 18:08:52,428 - ubuntuone.SyncDaemon.ActionQueue - DEBUG - Upload share:'' node:'e7469f58-c4b2-4326-932a-25bb2d4f2d18' Upload(share_id="''", hash="'sha1:580b8902e8e91d9ce038c44d115b67599c5f35ff'", running='False', node_id="'e7469f58-c4b2-4326-932a-25bb2d4f2d18'", upload_id="'2d1927b0-4377-5438-a1bc-811596d4ea58'", crc32='1135887907L', path="'/home/rtg/Ubuntu One/Test/file.ext'", previous_hash="''", size='1453065906') cleanup
2011-10-12 18:08:52,428 - ubuntuone.SyncDaemon.ActionQueue - DEBUG - Upload share:'' node:'e7469f58-c4b2-4326-932a-25bb2d4f2d18' Upload(share_id="''", hash="'sha1:580b8902e8e91d9ce038c44d115b67599c5f35ff'", running='False', node_id="'e7469f58-c4b2-4326-932a-25bb2d4f2d18'", upload_id="'2d1927b0-4377-5438-a1bc-811596d4ea58'", crc32='1135887907L', path="'/home/rtg/Ubuntu One/Test/file.ext'", previous_hash="''", size='1453065906') stopping the producer
2011-10-12 18:08:52,789 - ubuntuone.SyncDaemon.EQ - DEBUG - push_event: AQ_UPLOAD_ERROR, kwargs: {'share_id': '', 'hash': 'sha1:580b8902e8e91d9ce038c44d115b67599c5f35ff', 'node_id': 'e7469f58-c4b2-4326-932a-25bb2d4f2d18', 'error': 'I/O operation on closed file'}
2011-10-12 18:08:52,790 - ubuntuone.SyncDaemon.sync - DEBUG - T:LOCAL:F f0d9f74a-5251-429a-8df5-f160ae1c6bcb ['root'::'e7469f58-c4b2-4326-932a-25bb2d4f2d18'] ''Ubuntu One/Test/file.ext'' | EVENT: AQ_UPLOAD_ERROR:{'hash_eq_local_hash': 'T', 'hash_eq_server_hash': 'F', 'not_available': 'F', 'not_authorized': 'F'} with ARGS:('I/O operation on closed file', 'sha1:580b8902e8e91d9ce038c44d115b67599c5f35ff')
2011-10-12 18:08:52,793 - ubuntuone.SyncDaemon.sync - INFO - T:LOCAL:F f0d9f74a-5251-429a-8df5-f160ae1c6bcb ['root'::'e7469f58-c4b2-4326-932a-25bb2d4f2d18'] ''Ubuntu One/Test/file.ext'' | Calling nothing (got AQ_UPLOAD_ERROR:{'hash_eq_local_hash': 'T', 'hash_eq_server_hash': 'F', 'not_available': 'F', 'not_authorized': 'F'})
2011-10-12 18:08:52,794 - ubuntuone.SyncDaemon.sync - DEBUG - T:LOCAL:F f0d9f74a-5251-429a-8df5-f160ae1c6bcb ['root'::'e7469f58-c4b2-4326-932a-25bb2d4f2d18'] ''Ubuntu One/Test/file.ext'' | Called nothing
2011-10-12 18:08:52,797 - ubuntuone.SyncDaemon.ActionQueue - DEBUG - Upload share:'' node:'e7469f58-c4b2-4326-932a-25bb2d4f2d18' Upload(share_id="''", hash="'sha1:580b8902e8e91d9ce038c44d115b67599c5f35ff'", running='False', node_id="'e7469f58-c4b2-4326-932a-25bb2d4f2d18'", upload_id="'2d1927b0-4377-5438-a1bc-811596d4ea58'", crc32='1135887907L', path="'/home/rtg/Ubuntu One/Test/file.ext'", previous_hash="''", size='1453065906') semaphore released
2011-10-12 18:08:52,798 - ubuntuone.SyncDaemon.EQ - DEBUG - push_event: SYS_QUEUE_REMOVED, kwargs: {'command': <ubuntuone.syncdaemon.action_queue.Upload object at 0x7006500>}
2011-10-12 18:08:52,803 - ubuntuone.SyncDaemon.ActionQueue - DEBUG - Upload share:'' node:'e7469f58-c4b2-4326-932a-25bb2d4f2d18' Upload(share_id="''", hash="'sha1:580b8902e8e91d9ce038c44d115b67599c5f35ff'", running='False', node_id="'e7469f58-c4b2-4326-932a-25bb2d4f2d18'", upload_id="'2d1927b0-4377-5438-a1bc-811596d4ea58'", crc32='1135887907L', path="'/home/rtg/Ubuntu One/Test/file.ext'", previous_hash="''", size='1453065906') pathlock releasing ('', 'home', 'rtg', 'Ubuntu One', 'Test', 'file.ext'); remaining: 0

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: ubuntuone-client 2.0.0-0ubuntu2
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
Date: Wed Oct 12 18:14:12 2011
EcryptfsInUse: Yes
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
PackageArchitecture: all
SourcePackage: ubuntuone-client
UpgradeStatus: Upgraded to oneiric on 2011-08-30 (43 days ago)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[vasanag (vasanag)]

Hello,

as you suggested on the related bug (https://bugs.launchpad.net/ubuntuone-client/+bug/865059) I installed the new version of U1 for windows and after the synchronization I am sending you the attached the log files.

thanks,

Vassilis

[Natalia Bidart (nataliabidart)]

Hi Vassilis,

as you suggested in your original bug, your latest logs are not showing any error related to this bug report. I will reopen your bug and we can continue the debugging there.

Thanks a log for keep helping us!

Natalia.

[John A Meinel (jameinel)]

I'm seeing something similar to this on Oneiric.

I had a problem where a lot of my files were 0 bytes on U1. I don't know what caused this, but I used the U1 Android app and marked them all as deleted (I was on a walk when I noticed while trying to stream my music).

I then came home, and ran U1 on my laptop. I had a bunch of problems getting it back up and running, but now it seems to be connected, but not transferring any data.

I see a few of these ValueError lines, but not a huge number. I then see lines that look like:

2011-10-23 15:45:00,227 - ubuntuone.SyncDaemon.sync - INFO - T:LOCAL:F c5dc81f2-ff70-4598-92b8-2c4457657bff ['root'::'04b278fa-b421-488f-bf2b-d37dcd5a71df'] ''Ubuntu One/music/All Saints/All Saints/All Saints-Trapped.ogg'' | Calling commit_upload (got AQ_UPLOAD_FINISHED:{'hash_eq_local_hash': 'T', 'hash_eq_server_hash': 'F'})
2011-10-23 15:45:00,228 - ubuntuone.SyncDaemon.sync - INFO - T:NONE:F c5dc81f2-ff70-4598-92b8-2c4457657bff ['root'::'04b278fa-b421-488f-bf2b-d37dcd5a71df'] ''Ubuntu One/music/All Saints/All Saints/All Saints-Trapped.ogg'' | Called commit_upload (In: T:LOCAL:F)
2011-10-23 15:45:00,228 - ubuntuone.SyncDaemon.sync - INFO - T:NONE:F c5dc81f2-ff70-4598-92b8-2c4457657bff ['root'::'04b278fa-b421-488f-bf2b-d37dcd5a71df'] ''Ubuntu One/music/All Saints/All Saints/All Saints-Trapped.ogg'' | Updating current generation for volume to 8184

Which seems to say "mark that this file got uploaded, even though the hash doesn't match the server-side data." When I check on the website, the file does not appear to be there (so maybe the server realizes that it didn't get uploaded.)

When I check:
  u1sdtool --current-transfers

I see that the files it lists do change with time, though not very often. I also never see anything but "bytes written: 0" for each of those files.

While this is going on, I see probably 1000s of lines like:

2011-10-23 15:46:42,635 - ubuntuone.SyncDaemon.sync - INFO - -:-:- - [''::'6654bf47-61cb-484e-a05a-ea9860e95de2'] ''-'' | Calling clean_move_limbo (got AQ_MOVE_OK:{})
2011-10-23 15:46:42,635 - ubuntuone.SyncDaemon.sync - INFO - -:-:- - [''::'6654bf47-61cb-484e-a05a-ea9860e95de2'] ''-'' | Called clean_move_limbo (In: F:NA:NA)
2011-10-23 15:46:42,635 - ubuntuone.SyncDaemon.sync - INFO - -:-:- - [''::'6654bf47-61cb-484e-a05a-ea9860e95de2'] ''-'' | Updating current generation for volume to 8347

and

2011-10-23 15:51:45,434 - ubuntuone.SyncDaemon.sync - INFO - -:-:- - [''::'2a189b40-f14c-4e04-97e1-2d8888130346'] ''-'' | Calling remove_trash (got AQ_UNLINK_OK:{})
2011-10-23 15:51:45,435 - ubuntuone.SyncDaemon.sync - INFO - -:-:- - [''::'2a189b40-f14c-4e04-97e1-2d8888130346'] ''-'' | Called remove_trash (In: F:NA:NA)
2011-10-23 15:51:45,435 - ubuntuone.SyncDaemon.sync - INFO - -:-:- - [''::'2a189b40-f14c-4e04-97e1-2d8888130346'] ''-'' | Updating current generation for volume to 8876

(It starts at generation 8514, and as you can see has reached 8876, note that when I started today, I see generation 5948, so somehow I've gone through ~3000 generations while it tries to do this stuff.)

The most recent log message says I'm at generation 9256.

[Facundo Batista (facundo)]

The Upload's temp file is being closed at the end of the '_run'.

We need to remove that closing from there, and only close the file at the very end of the command, when the file is also removed from disk (which is today being done in 'handle_failure' and 'handle_success', and could be done in 'finish' so it also includes the command being cancelled).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Chris Halse Rogers (raof)]

This does not seem to be fixed in Precise yet. Once it's fixed there, the SRU looks good, and we can accept the package into oneiric-proposed.

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntuone-client - 2.0.0-0ubuntu3

---------------
ubuntuone-client (2.0.0-0ubuntu3) precise; urgency=low

  * debian/patches/02_value_io_error_fix.patch:
      - Make the Upload process do not close the tempfile until is finished
        (LP: #872924).
      - Reset the tempfile on every Upload _run() (LP: #884959).
 -- Natalia Bidart (nessita) <email address hidden> Mon, 14 Nov 2011 11:16:03 -0300

[Clint Byrum (clint-fewbar)]

Hello Roman, or anyone else affected,

Accepted ubuntuone-client into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Joshua Hoover (joshuahoover)]

Verified test case passed using proposed ubuntuone-client 2.0.0-0ubuntu2.1

[Andre (ajx)]

I've tested the new ubuntuone-client 2.0.0-0ubuntu2.1 from oneric proposed with negative result.

I've put a file TEST.zip (212MB) into the U1 folder (at 2011-11-17 11:11:43). I'm connect by a 1 GBit/s line. However, the upload speed of the U1 client is horrible slow peaking at 600kB/s, mostly averaging about 60kB/s, periodically creeping at 0 (while uploads via web interface reach 5MB/s). After 1.5 hours the Gnome System Monitor shows that more the 212 MB have been uploaded, but the file does not appear in U1 on the web, and locally the file has still the emblem "syncing" in Nautilus. Under .cache/ubuntuone/log I found the file syncdaemon-exceptions.log stating:

2011-11-17 11:51:14,590 - ubuntuone.SyncDaemon.ActionQueue - ERROR - Upload
... (some hash values) ...
failure: I/O operation on closed file (traceback follows)
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/ubuntuone-client/ubuntuone/syncdaemon/action_queue.py", line 1370, in run
    result = yield self.running_deferred
ValueError: I/O operation on closed file

It is still not possible to get big files uploaded to U1.

[dobey (dobey)]

@Andre, did you restart ubuntuone-syncdaemon after the upgrade? If you upgraded, but never restarted syncdaemon, the same issue would recur as the new code would not be running. I just uploaded a 62MB video without any problems here, and it only took a few seconds to upload.

[Andre (ajx)]

@Rodney, of course. I even rebooted the system to be sure all components get restarted.

Please try to get files > 200 MB synced. The FAQ of U1 state that file sizes up to 5TB should be not problem: https://one.ubuntu.com/help/faq/what-is-the-largest-size-file-i-can-sync-with-ubuntu-one/

[dobey (dobey)]

@Andre, I now just uploaded a 280MB file, anad it worked fine. Are you sure you're using the updated ubuntuone-client? What does "apt-cache policy ubuntuone-client python-ubuntuone-client" say for you?

[Andre (ajx)]

I've put in another file with 828 MB. After transferring some 86 MB the sync died again, and U1 pretends to be IDLE. I have the feeling that the pattern behind this is the transfer rate which is somewhat variable from 1MB/s (what is still slow in comparison to other sync services out there) to some kB/s (<10). Again, I'm on a 1GBit/s line. Once the transfer rate creeps slightly above 0, the sync daemon throws an error, and I get a notification stating that the upload of my file has just started followed by a notification that the transfer is complete (what can't be true if only 86 MB went through eth0 while the file size is 828 MB):

2011-11-18 14:57:09,260 - ubuntuone.status - DEBUG - server connection made
2011-11-18 15:14:01,417 - ubuntuone.status - DEBUG - queueing command (total: 0): Upload
2011-11-18 15:14:02,064 - ubuntuone.status - DEBUG - notification shown: »TEST2.zip« wird in Ihren persönlichen Online-Speicher hochgeladen.
2011-11-18 15:20:00,385 - ubuntuone.status - DEBUG - progressbar shown
2011-11-18 15:20:00,488 - ubuntuone.status - DEBUG - progressbar updated: 0.081356
2011-11-18 15:23:38,138 - ubuntuone.status - DEBUG - server connection lost
2011-11-18 15:23:40,728 - ubuntuone.status - DEBUG - server connection made
2011-11-18 15:23:40,815 - ubuntuone.status - DEBUG - notification shown: »TEST2.zip« wird in Ihren persönlichen Online-Speicher hochgeladen.
2011-11-18 15:23:40,873 - ubuntuone.status - DEBUG - server connection lost
2011-11-18 15:23:45,143 - ubuntuone.status - DEBUG - server connection made
2011-11-18 15:23:45,162 - ubuntuone.status - DEBUG - notification shown: »TEST2.zip« wird in Ihren persönlichen Online-Speicher hochgeladen.
2011-11-18 15:23:46,889 - ubuntuone.status - DEBUG - unqueueing command: Upload
2011-11-18 15:23:46,942 - ubuntuone.status - DEBUG - queue done callback added
2011-11-18 15:23:46,990 - ubuntuone.status - DEBUG - progressbar updated: 1.000000
2011-11-18 15:23:56,943 - ubuntuone.status - DEBUG - queue done callback fired
2011-11-18 15:23:57,010 - ubuntuone.status - DEBUG - progressbar hidden

So the percentage transferred jumps from 8% to 100%.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
syncdaemon-exceptions.log:

2011-11-18 15:23:46,782 - ubuntuone.SyncDaemon.ActionQueue - ERROR - Upload share:'' node:'...' Upload(share_id="''", hash="'...'", running='False', node_id="'...'", upload_id='None', crc32='133509230L', path="'/.../Ubuntu One/TEST2.zip'", previous_hash="''", size='828164869') failure: I/O operation on closed file (traceback follows)
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/ubuntuone-client/ubuntuone/syncdaemon/action_queue.py", line 1370, in run
    result = yield self.running_deferred
ValueError: I/O operation on closed file

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

apt-cache policy ubuntuone-client python-ubuntuone-client:

python-ubuntuone-client:
  Installiert: 2.0.0-0ubuntu2.1
  Kandidat: 2.0.0-0ubuntu2.1
  Versionstabelle:
 *** 2.0.0-0ubuntu2.1 0
        500 http://ubuntu.osuosl.org/ubuntu/ oneiric-proposed/main i386 Packages
       ...

[Andre (ajx)]

I tested to new client from 'proposed' on a friends machine. Although the transfer rates are very slow (even over our 1GBit/s internet connection) and the upload of 700+ MB has not finished yet, the client seems to be working on the upload (at 0 kB/s though) without running into this bug. This brings me to three conclusions:

1) this bug might be fixed. but not for me. :-(

2) something is wrong with my installation/configuration/cache of U1. How to fix it? I didn't do anything unusual. It should just work.

3) the slow transfer speed to U1 servers makes tracking down of bugs very hard because I never know if it is a local or server problem.

[Joshua Hoover (joshuahoover)]

Andre,

Are you seeing the error logged in ~/.cache/ubuntuone/log/syncdaemon-exceptions.log? Did you disconnect and reconnect to Ubuntu One after installing this proposed package?

[dobey (dobey)]

Sorry. The package is broken and the patch didn't actually get applied when building.

[Andre (ajx)]

@Joshua,

yes, the error is logged to ~/.cache/ubuntuone/log/syncdaemon-exceptions.log (see comment #13 & #17). And yes, I reconnected to U1 service because I rebooted the machine (see comment #15).

@Rodney,

when will a new build of the package arrive in 'proposed'?

[Martin Pitt (pitti)]

Hello Roman, or anyone else affected,

Accepted ubuntuone-client into oneiric-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Andre (ajx)]

Tested 2 big files (230 and 560 MB) with the new build (2.0.0-0ubuntu2.2). Result: It works! Both files were uploaded very fast without any interruptions.

Thank you for fixing this!

Don't know if this is related to the new version: I had stable upload rates at 1-3 MB/s (MByte!). Even the conformation of the server that the file was successfully uploaded came fast.

[crazy ivan (x-floc)]

UbuntuOne is a total nuisance :(

After having not used it for a year for the reason of above bugs, I decided to give it another try with oneric. No luck.. Now I tried it with the latest version from proposed. Upload of 1 GB file got stuck with

"ubuntuone.SyncDaemon.ActionQueue - ERROR - Upload",

im my case not being uploaded, not being listed as waiting, not being listed on site, just showing updating icon in nautilus, while containing folder shows OK

So reconnect / restart daemon changed nothing.. Restart of computer brought the file to waiting again. No status change for 30 min, so I decide to add some files to the directory and remove them right away.. The file disappears from syncdaemon's radar again with the following message

cat ~/.cache/ubuntuone/log/syncdaemon-exceptions.log
2011-11-29 12:39:22,876 - twisted - ERROR - Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 84, in callWithLogger
    return callWithContext({"system": lp}, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/log.py", line 69, in callWithContext
    return context.call({ILogContext: newCtx}, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 118, in callWithContext
    return self.currentContext().callWithContext(ctx, func, *args, **kw)
  File "/usr/lib/python2.7/dist-packages/twisted/python/context.py", line 81, in callWithContext
    return func(*args,**kw)
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/gtk2reactor.py", line 288, in _doReadOrWrite
    why = source.doRead()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 137, in doRead
    return Connection.doRead(self)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/tcp.py", line 460, in doRead
    rval = self.protocol.dataReceived(data)
  File "/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol/ubuntuone/storageprotocol/client.py", line 1601, in dataReceived
    StorageClient.dataReceived(self, data)
  File "/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol/ubuntuone/storageprotocol/client.py", line 91, in dataReceived
    request.RequestHandler.dataReceived(self, data)
  File "/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol/ubuntuone/storageprotocol/request.py", line 143, in dataReceived
    self.buildMessage(data)
  File "/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol/ubuntuone/storageprotocol/request.py", line 163, in buildMessage
    self.buildMessage(data[:p])
  File "/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol/ubuntuone/storageprotocol/request.py", line 190, in buildMessage
    self.processMessage(message)
  File "/usr/lib/python2.7/dist-packages/ubuntuone-client/ubuntuone/syncdaemon/action_queue.py", line 272, in processMessage
    result = ThrottlingStorageClient.processMessage(self, message)
  File "/usr/lib/python2.7/dist-packages/ubuntuone-storage-protocol/ubuntuone/storageprotocol/request.py", line 232, in processMessage
    str(message).replace("\n", " ")))
exceptions.Exception: peer cant handle message 'CANCELLED' {id: 33...

[Sergei Vorobyov (svorobyov)]

agreed, it's rubbish, never worked and never will. I used to give it a try once a few months but now completely fed up. Waste of your time + loss of your data. This project should be cancelled asap as causing irreparable damage to Ubuntu and Linux

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntuone-client - 2.0.0-0ubuntu2.2

---------------
ubuntuone-client (2.0.0-0ubuntu2.2) oneiric-proposed; urgency=low

  * debian/patches/02_value_io_error_fix.patch:
      - Make the Upload process do not close the tempfile until is finished
        (LP: #872924).
      - Reset the tempfile on every Upload _run() (LP: #884959).
 -- Natalia Bidart (nessita) <email address hidden> Mon, 14 Nov 2011 11:16:03 -0300

[papukaija (papukaija)]

@crazy ivan and Sergei: Please open a new bug for your issue as they aren't related to this bug. Thanks in advance.

[Chris Bainbridge (chris-bainbridge)]

This bug isn't fixed. I am using ubuntuone-client 2.0.0-0ubuntu2.3 on Oneiric. Installed yesterday.

I have attached syncdaemon-exceptions.log from today and yesterday.

[Chris Bainbridge (chris-bainbridge)]

Here is yesterday's exception log, as you can see there are many exceptions.

[Chris Bainbridge (chris-bainbridge)]

With all of these exceptions syncdaemon is just hung. There is no syncing taking place.

[Chris Bainbridge (chris-bainbridge)]

Note there is also this exception appearing many times:

2012-02-15 17:25:31,788 - ubuntuone.SyncDaemon.ActionQueue - ERROR - Upload share:'' node:marker:aa9f5300-d6f1-4dda-9084-e55bb84afe2d Upload(share_id="''", hash="'sha1:c4d7f9c29211cd563e50931e4399c42f6376e38e'", running='False', node_id='marker:aa9f5300-d6f1-4dda-9084-e55bb84afe2d', upload_id='None', crc32='3619746396L', path="'/home/user/Ubuntu One/enc/XSiACnZbU2VHyOlY6luN,0EF/7Hi6pKcboetRQnzo0a9X-b1Q/cUfooIAzi2TVsDXUt60VmSlT/z89FtlYCeQlCy7EX8bSsf2dB/WbF5H8RZuoqXoWtD0G3zX-Yl/UHi6JuG-4QppHMlAhwE5rnAVgZw9JnP,itdgDWxraipLq-'", previous_hash="''", size='12361') Error running the command: [Errno 24] Too many open files: '/tmp/tmp8noMsG' (traceback follows)
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/ubuntuone-client/ubuntuone/syncdaemon/action_queue.py", line 1313, in go
    yield self.run()
OSError: [Errno 24] Too many open files: '/tmp/tmp8noMsG'

And also this error where syncing seems to have stopped:

2012-02-16 12:30:50,088 - twisted - ERROR - Unhandled error in Deferred:
2012-02-16 12:30:50,092 - twisted - ERROR - Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/gtk2reactor.py", line 316, in simulate
    self.runUntilCurrent()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 766, in runUntilCurrent
    f(*a, **kw)
  File "/usr/lib/python2.7/dist-packages/ubuntuone-client/ubuntuone/syncdaemon/main.py", line 265, in quit
    self.shutdown(with_restart)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1141, in unwindGenerator
    return _inlineCallbacks(None, f(*args, **kwargs), Deferred())
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1020, in _inlineCallbacks
    result = g.send(result)
  File "/usr/lib/python2.7/dist-packages/ubuntuone-client/ubuntuone/syncdaemon/main.py", line 220, in shutdown
    self.external.shutdown(with_restart)
  File "/usr/lib/python2.7/dist-packages/ubuntuone-client/ubuntuone/platform/linux/__init__.py", line 95, in shutdown
    self.dbus_iface.shutdown(with_restart)
  File "/usr/lib/python2.7/dist-packages/ubuntuone-client/ubuntuone/platform/linux/dbus_interface.py", line 1327, in shutdown
    self.status.remove_from_connection()
  File "/usr/lib/python2.7/dist-packages/dbus/service.py", line 621, in remove_from_connection
    '(%r,%r)' % (self, connection, path))
exceptions.LookupError: <ubuntuone.platform.linux.dbus_interface.Status at /status at 0x2e8a490> is not exported at a location matching (None,None)

2012-02-16 12:30:50,094 - twisted - ERROR - Unhandled Error
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/twisted/internet/gtk2reactor.py", line 270, in run
    self.__run()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/gtk2reactor.py", line 141, in wrapper
    return real_cb(real_s, condition)
  File "/usr/lib/python2.7/dist-packages/twisted/internet/gtk2reactor.py", line 306, in callback
    self.simulate() # fire Twisted timers
  File "/usr/lib/python...

[Chris Bainbridge (chris-bainbridge)]

The exceptions in those logs seem seems to be:

bug #872924 (this bug) ubuntuone.SyncDaemon.ActionQueue - ERROR - Upload File ... I/O operation on closed file

bug #739688 ubuntuone.SyncDaemon.sync - ERROR - Node delta for :... can't be applied.
(note that one is supposed to be fixed)

bug #751844 ubuntuone.SyncDaemon.EQ - ERROR - Error encountered while handling: AQ_DIR_NEW_OK in <ubuntuone.eventlog.zg_listener.ZeitgeistListener object at ...>

bug ? ubuntuone.SyncDaemon.ActionQueue - ERROR ... syncdaemon/action_queue.py ... OSError: [Errno 24] Too many open files: '/tmp/tmpON9jQq'

Can't find a bug for the last one, if it isn't related to this bug please tell me and I will open a new one.

(Hard to believe that I start using Ubuntu One and hit so many bugs within 24 hours! The software is, at the moment, unusable for me.)

[papukaija (papukaija)]

This bug is fixed. Please open a new bug for your issue. Thanks in advance.

[Sergei Vorobyov (svorobyov)]

Ubutu One is the biggest failure inflicting on the GNU/Linux/Ubuntu public image.

This project should be stopped ASAP to cause no further damage to Linux and Ubuntu.

I am regularly reporting on their big time failures ,just trying to install and run Ubuntu One on different platforms (I would never entrust them my real data though).

Today's installation error (I erased the previous version completely):

"Sorry, an error has occurred and Ubuntu One needs to close. Zimport error: bad local file header in C:Program Files (x86)\ubuntu one\dist\libray.zip"

Could anyone knowledgeable hint the Ubuntu leadership to stop this hackwork?

I take it very seriously and will persist until they stop spoiling the Linux reputation.

[Roberto Alsina (ralsina)]

Sergei, thanks for taking the time to test Ubuntu One.

That error message seems to point to a disk failure or corrupted dowload, since the only way to cause it is to have a corrupt or truncated library.zip.

On the other hand, your problem is obviously unrelated to the issue where you posted it, which is annoying to those who are subscribed to it because they were affected.

Please, if you do care about getting it fixed, create a new bug report. It does seem like something that has not been reported by the previous several hundred thousand installs.