Ubuntu One Client

[maverick] ubuntuone-launch fails to connect syncdaemon if get_metadata times out

Bug #635636 reported by Roman Yepishev
88
This bug affects 39 people
Affects Status Importance Assigned to Milestone
Ubuntu One Client
Confirmed
Medium
Ubuntu One Client Engineering team

Bug Description

STR:

1. Put a lot of files in Ubuntu One folder
2. Make sure ubuntuone-launch is listd in gnome-session-properties
3. Reboot to clear the cache
4. Log in
5. Wait for gsd & nautilus to trigger syncdaemon startup
6. Wait for 30 seconds or more depending of the amount of files put into Ubuntu One folder in step 1
7. Check u1sdtool --status

Expected result:
QUEUE_MANAGER

Actual result:
READY

Reason:
           try:
                # have SD start
                d = sync_daemon_tool.start()
                d.addCallback(wait_for_ready, sync_daemon_tool)
           ...

wait_for_ready is called only when syncdaemon is started by ubuntuone-launch, therefore the callback code calls sync_daemon_tool.get_metadata(U1ROOT) and this callback produces an error due to syncdaemon D-Bus service not being up at that moment.

If d.addCallback(wait_for_ready, sync_daemon_tool) added before get_metadata() callback registration, this will work but that opens up another issue - READY can be reached before ubuntuone-launch is started and StatusChanged signal may never be seen.

Revision history for this message
John Lenton (chipaca) wrote :

This would be fixed and/or mitigated a lot when syncdaemon stops getting started by nautilus/gsd, right?

Revision history for this message
Roman Yepishev (rye) wrote :

Yes, when syncdaemon is not started prior to ubuntuone-launch then this issue should be less visible for the user.

Joshua Hoover (joshuahoover)
Changed in ubuntuone-client:
importance: High → Medium
Joshua Hoover (joshuahoover)
tags: added: u1-maverick-sru
removed: u1-maverick
Revision history for this message
hanzz (hans-prueller) wrote :

I am having really lots of files within my ubuntuone folder(s) and I am running 2 machines-desktop and netbook.

I have experienced that ubuntuone syncs nothing because it fails to connect automatically on both machines; even if I let the machine up and running in idle state for hours -- u1 won't connect and continue syncing.

also when I try to connect manually via terminal I have to give it several tries until it succeeds, e.g. this is what I had to do today:

============
u1hansp@smithers:~$ u1sdtool -c

Oops, an error ocurred:
Traceback (most recent call last):
Failure: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
hansp@smithers:~$ u1sdtool -c

Oops, an error ocurred:
Traceback (most recent call last):
Failure: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
hansp@smithers:~$ u1sdtool -c
hansp@smithers:~$
hansp@smithers:~$ u1sdtool -s
State: LOCAL_RESCAN
    connection: With User With Network
    description: doing local rescan
    is_connected: False
    is_error: False
    is_online: False
    queues: WORKING_ON_BOTH
hansp@smithers:~$

============

Revision history for this message
phillamg (me-phillg) wrote :

I'm also having this issue. I thought it was bug 651237 but technically the daemon is not quiting, it's just not connecting. Using the latest version from maverick-proposed, 1.4.5, these are the responses to 'u1sdtool -s' after logging in:

[Inside 1 min]
Oops, an error ocurred:
Traceback (most recent call last):
Failure: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

[After 2 mins]
State: LOCAL_RESCAN
    connection: Not User With Network
    description: doing local rescan
    is_connected: False
    is_error: False
    is_online: False
    queues: WORKING_ON_METADATA

[After 4 mins]
State: READY
    connection: Not User With Network
    description: ready to connect
    is_connected: False
    is_error: False
    is_online: False
    queues: WORKING_ON_BOTH

At no point does U1 connect or think it is online despite a wired connection (managed through Network Manager) that every other application has no problem with. Once the initial DBus oops error has finished the workaround is to quit and restart u1sdtool daemon.

Revision history for this message
Daniel Landsverk (daniel-landsverk) wrote :

Same problem here as well, and now only with ONE file pending.
I've filed this bug before, but it suddenly got deleted, so I'm posting the output of 'u1sdtool --status' here:

daniel@daniel-K53SV:~$ u1sdtool --status
State: WAITING
    connection: With User With Network
    description: waiting before try connecting again
    is_connected: False
    is_error: False
    is_online: False
    queues: WORKING

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.