Requires correct time and date (timezone) be set on client; should warn if not

If I'm reading this correctly, I can confirm it. Upon startup or applet load, the applet fails to connect to the server. I ran "ubuntuone-client-applet" in a terminal window and got the same results. The applet showed activity by rotating the Ubuntu logo and then disconnected -- the terminal showed no text.

Thanks for submitting a bug report !

Could you attach your ~/.cache/log/syncdaemon.log file ?
This should show us what's causing this behaviour.

Attached is my syncdaemon.log

The client is also consuming 40-50% CPU when running. It worked fine until yesterday. Also -- my oauth-login.log is 295.6 *mega*bytes; is that normal?

It seems the client is failing to authorise and hanging.

Indeed:

2009-07-14 23:24:56,926 - ubuntuone.SyncDaemon.EQ - DEBUG - push_event: SYS_STATE_CHANGED, args:(), kw:{'state': <NonActiveConnectedSDState START_AUTHENTICATING>}

2009-07-14 23:24:57,395 - ubuntuone.SyncDaemon.Main - ERROR - OAuth failed: [Failure instance: Traceback (failure with no frames): <class 'ubuntuone.storageprotocol.request.StorageProtocolError'>: Authentication Failed]

Can you also attach a peice of that oauth-login.log ?

I did a complete reinstall last night and the oauth-login.log is already 3.9 MB. Still having the same problem though. oauth-login.log attached.

Try opening Accessories->Passwords & Encryption Keys, and removing the "UbuntuOne token" from the Passwords tab, and then quit and start the applet again.

Rodney Dawes: No go. Didn't work.

I'm surprised that didn't work - can you give more info on what happened, and post the log files again ?

Maybe it's best if you first stop the applet, then delete all log files (rm ~/.cache/ubuntuone/log/*), then delete the Ubuntuone token, and then restart the applet. That way, the log files won't be too big.

Normally, when you do what Rodney Dawes suggested, the browser opens the Ubuntuone website, asking if you want to add this PC to your Ubuntuone account (and asking you to login, if you weren't already).

Then, when you accept, the syncdaemon should start syncing, without giving that authentication failure.

Tom: Sorry for the long delay in replying. That did the trick. I'm connecting and syncing properly now. Thanks a lot.

Aha, I'm glad to hear that fixed it !
But we have Rodney Dawes to thank for most of it, I just re-stated his instructions.

I'm not quite sure about what to do with this bug ("fix released", "question", "invalid" ?).

The fact that this happened to a user, who then has to come here to ask for help, does seem to imply that somewhere, something is wrong, so this seems like a bug. What I don't know, is how to reproduce it.

Tom: Try starting ubuntu without connecting to any network, then killing the applet. Doing that has caused the problem to reappear on my machine.

Here's a fresh set of logs for this session. What worked before doesn't work now.

I'm not using Ubuntu One at the moment (I'm still having trouble because of Bug #399713) but I as you can see from your logs, the client cannot find an Authorisation Token, so it tries to download one.

But that fails, because:
"2009-07-26 16:25:48,291:291.05091095 UbuntuOne.OAuthDesktop.auth Token was not successfully retrieved: data was 'Expired timestamp: given 1248643546 and now 1248661547 has a greater difference than threshold 300'"

When converting those 2 timestamps to dates, I get the following:
1248643546 = Sun, 26 Jul 2009 21:25:46 GMT
1248661547 = Mon, 27 Jul 2009 02:25:47 GMT

Weird ! My best guess is that the date on the server is compared to the date on your machine, but they differ, because you are in a different timezone. I bet that, if you set your clock 5 hours further, the problem will go away.

The strange thing is that this doesn't seem to happen to other people, at least not before today...

Would you mind creating a new bug report for this problem ? I don't feel like the right person for it, because I'm not using UbuntuOne and therefore cannot reproduce your problem.

Try using a clear title, for example: "Cannot retrieve token because of expired timestamp (timezone problem ?)"

Thanks !

Put simply the clock on the machine is wrong (it is out by five hours).

Go into System->Administration->Time and Date... click "Unlock" and ensure that the Timezone is whereever you live/work. (Not "GMT" or "Europe/London").

Probably a better fix is to stick to local time_t when on the local machine, and stick to server time_t when on the server?

I found the problem with my time settings - my Windows install changes the
time when I boot into it. I started my machine this morning after setting
the correct time last night. Firefox opened, asked for authorisation and all
is well again. Now I feel stupid for wasting your time. At least we did
learn a couple things. Like this:

Users of NoScript should temporarily disable NoScript Options -> Advanced ->
Abe when adding new authorisations. Abe is set to automatically block this
action.

Anyway, Thanks for all the help and patience.

On Mon, Jul 27, 2009 at 2:32 AM, Paul Sladen <email address hidden> wrote:

> Put simply the clock on the machine is wrong (it is out by five hours).
>
> Go into System->Administration->Time and Date... click "Unlock" and
> ensure that the Timezone is whereever you live/work. (Not "GMT" or
> "Europe/London").
>
> ** Summary changed:
>
> - ubuntu one client bug
> + Requires correct time and date (timezone) be set on client; should warn
> if not
>
> --
> Requires correct time and date (timezone) be set on client; should warn if
> not
> https://bugs.launchpad.net/bugs/399805
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I found the problem with my time settings - my Windows install changes the time when I boot into it. I started my machine this morning after setting the correct time last night. Firefox opened, asked for authorisation and all is well again. Now I feel stupid for wasting your time. At least we did learn a couple things. Like this:

Users of NoScript should temporarily disable NoScript Options -> Advanced -> Abe when adding new authorisations. Abe is set to automatically block this action.

Anyway, Thanks for all the help and patience.

Not at all, thank you for pointing this out.
It's an issue that may affect many users, so I don't feel like time has been wasted here.

This should be addressed so that users do not have to troubleshoot in this way.