Connection timeout / syncronisation restarts but fails again and again

[Rocologo]

This bug is the same as #1893 (#1893)

I got the errors over and over again on the same files...

"Connection timeout"
"Operation canceled"
"Operation canceled"

While looking for a solution I noticed #1893 which is closed but never fixed. Developer Guruz asked to test if "enabling bandwidth" changed anything. And the answer is yes. It gave me a workaround, and now my syncronisation is running smoothly again. (with limited bandwidth)

[guruz]

@Rocologo Hi! Which platform are you on? Did you update to the latest server?

[Rocologo]

My server is Debian 7.6 with Openmediavault 1.0 installed on top and my client is Linux Mint 17. And yes my server is running owncloud 7.0.2.1 and the client is 1.6.3.

[ckamm]

@Rocologo You are saying this is similar to #1893 in that it happens after your computer wakes from sleep? Or is this unrelated to suspending?

There were some timeout related changes in 1.7 and 1.6.4, maybe you could try to reproduce the issue with the latest snapshot from http://download.owncloud.com/desktop/daily/ ?

To look at your issue in detail I'd need your client log files (start the client with --logfile mylogfile) to see where the timeout happens exactly and what else was going on at the time.

[Rocologo]

Hi Mirall

1.6.4 was just published in the official repository so I will test this
version first, to see if I still get this bug. :-|

I don't think my problem was related to suspension, but the description
of the error message was exactly the same. Sorry for the confusion.

Im syncronizing ~200.000 files (mostly small files < 1) and the "prepare
for syncronisation" takes hours before it actually start. And when it
starts its very slow syncronisation even though the files are very small.

Kind regards
Rocologo

On 10/22/2014 11:11 AM, ckamm wrote:

@Rocologo https://github.com/Rocologo You are saying this is similar
to #1893 #1893 in that it
happens after your computer wakes from sleep? Or is this unrelated to
suspending?

There were some timeout related changes in 1.7 and 1.6.4, maybe you
could try to reproduce the issue with the latest snapshot from
http://download.owncloud.com/desktop/daily/ ?

To look at your issue in detail I'd need your client log files (start
the client with --logfile mylogfile) to see where the timeout happens
exactly and what else was going on at the time.

—
Reply to this email directly or view it on GitHub
#2323 (comment).

[Rocologo]

Hi again

I have now tested version 1.6.4, but it has the same problem.

I cant catch the log (F12) because Im syncronising ~200.000 files / ~
6GB data so the error are flushed before I can grab the part of the log
where the connection fails. Is there anyway I can catch the full log ?
Can I tell the client to write the log direct to an file or something
like that?

On 10/22/2014 11:11 AM, ckamm wrote:

@Rocologo https://github.com/Rocologo You are saying this is similar
to #1893 #1893 in that it
happens after your computer wakes from sleep? Or is this unrelated to
suspending?

There were some timeout related changes in 1.7 and 1.6.4, maybe you
could try to reproduce the issue with the latest snapshot from
http://download.owncloud.com/desktop/daily/ ?

To look at your issue in detail I'd need your client log files (start
the client with --logfile mylogfile) to see where the timeout happens
exactly and what else was going on at the time.

—
Reply to this email directly or view it on GitHub
#2323 (comment).

[dragotin]

please refer to http://doc.owncloud.org/desktop/1.6/troubleshooting.html#log-files on how to save the logfiles directly.

[Rocologo]

Okay, I have found out how to grab the log to an file:

|owncloud --logfile owncloud-client.log

||I will make a log file for you, where the error appears.

|
|

@Rocologo https://github.com/Rocologo You are saying this is similar
to #1893 #1893 in that it
happens after your computer wakes from sleep? Or is this unrelated to
suspending?

There were some timeout related changes in 1.7 and 1.6.4, maybe you
could try to reproduce the issue with the latest snapshot from
http://download.owncloud.com/desktop/daily/ ?

To look at your issue in detail I'd need your client log files (start
the client with --logfile mylogfile) to see where the timeout happens
exactly and what else was going on at the time.

—
Reply to this email directly or view it on GitHub
#2323 (comment).

[ckamm]

@Rocologo Thank you. It it turns out to be too big, feel free to cut to to a few thousand lines around the timeout.

[Rocologo]

Hi ckamm

The log files became extremely big because my the syncronisation worked all day until I "hibernated" my virtual computer. (Its a Linux Mint 17 running on windows through VirtualBox). Next morning when I resumed my virtual computer. The error ocurred. And then I "limitted the bandwidth" and got it up and running again.

I have saved the client log, the owncloud server log and the nginx log. Are you still interested to see the logs?

[ckamm]

@Rocologo If you can give me the logs (in particular the client log), that'd be the easiest way for me to figure out what may be going on. If they're too big, something like 'grep -C1000 -i timeout clientlog > reducedlog' may already be good enough.

Your particular failure case was this:

• a huge sync folder needs to be uploaded
• eventually computer hibernates (by suspending the virtualbox vm)
• after resuming the vm the current sync aborts (that's likely hard to avoid)
• all following syncs also fail with a timeout error
• the problem is solved by restarting the client

Is this correct?

[ckamm]

Oh, and 'prepare for synchronization' taking hours is also something we should look at. This is on linux, with 200.000 small local files and nothing on the server?

[Rocologo]

Hi ckamm

Sorry for the delay. Here is my log files, the timeout error happened at 8:59 the 24/10-2014:

Nginx logfile:
https://www.lindegaard.tk:8443/public.php?service=files&t=733d413f0a137e2cc434dfce5dc02376

ownCloud client log file:
https://www.lindegaard.tk:8443/public.php?service=files&t=e1836b502c894e46896b0d15f2ef2dc4

ownCloud Server log file:
https://www.lindegaard.tk:8443/public.php?service=files&t=fbeee4b9898972108afe335dee374afa

I have saved the full log files but they are about 400Mb.

[ckamm]

In your log file I see that an upload job that was running before you hibernated timed out once you resumed. That much looks like an expected error.

Then it tries a fresh sync but fails early:

10-24 09:01:13:705 oc_module: WRN: propfind named failed with 2, request error: Could not resolve hostname `www.lindegaard.tk': Host not found
10-24 09:01:15:032  #### ERROR during  csync_update :  "CSync failed to lookup proxy or server. Could not resolve hostname `www.lindegaard.tk': Host not found" 

and the same thing happens again and again. @Rocologo restarting the client makes it work again?

[Rocologo]

I have tried both restarting the owncloud client and the computer it
self. In both situations, it started over, "preparing sync" for hours,
and when that’s done the synchronisation starts again. But because the
"preparing" and the "synchronisation" took hours/days, I had to
hibernate again. And when restarting the error happened again.

I’mnot 100% sure, but I think I happened with the same files again. Its
a bit hard to remember, but in the end I enabled "limit bandwidth" and
got the files synchronised in many days.

On 11/05/2014 09:39 AM, ckamm wrote:

the same thing happens again and

[Rocologo]

FYI. My computer is a laptop and when I hibernate it is usually because Im going to/from work, which means that my IP address changes and that my DNS server also changes. www.lindegaard.tk is public so I dont know why the client cant resolve the name.... at work we have a real proxy, at home I only have my router acting as router/firewall/proxy.

As written earlier my Laptop is running Windows 7, but for private use I'm using Virtualbox 4.3.12, with a Linux Mint 17 on top. I have mostly tried NAT networking setting on the virtual computer, but I tried also bridged, to see if that could speed up the syncronisation. I did not solve the problems using bridged network :-( so today Im using NAT again.

Please let me know if you need more info.

[ckamm]

@Rocologo Searching for other users with that issue lets me think this may be a Windows DNS issue. Can you try

net stop dnscache
net start dnscacne

after hibernation? Or disabling or restarting the "DNS client" service?

See
http://forums.vr-zone.com/troubleshooting-zone-technical-enquiries/181329-dns-problem-after-hibernate-wakeup.html
http://superuser.com/questions/411607/dns-lookup-fails-after-resume-from-sleep
http://answers.microsoft.com/en-us/windows/forum/windows_7-networking/windows-7-no-dns-or-no-network-after-resume-wake/c1253ab0-4793-449e-8975-a900ce7dec4f

That last link suggests that virtual network adapters, like for virtualbox, somehow break DNS operation over wireless after resuming. Is only the ownCloud client affected?

[Rocologo]

Actually no. Its very often when I turn on the computer at work, I have to do something to make the network inside virtualbox work.
a) Sometimes i change between NAT and Bridged
b) Sometimes i disconnect the "virtual cable" in virtualbox
I think that the DNS will be refreshed in both situations and after doing so my browser works again, but I dont think this fixed the error in ownclod syncronisation.

I will try to syncronise some files and see if I can recreate the error, and the do the net stop/start dnscache on my Windows client. And then I will get back to you.

[Rocologo]

I have not been able to provoke the error again, and I have spend some time on reading the links you send me. They are are all about Windows DNS not working after hibernating. This is not the same as my problem. My Windows 7 host works fine, its only my virtual linux mint 17 which seems to have problems after hibernating (both) computers.

It seems that I cant provoke the error when I syncronize a small number (~1000) of files, and I dont have the time to syncronize 20.000 files, because of the syncronisation speed. Its my Eclipse development environment I syncronice, between my laptop and stationary.

[ckamm]

@Rocologo Yes, I understand. At this point I'm just guessing and it seems most likely that this isn't a client issue but an issue somewhere down the stack. Let me summarize your issue to see if I got it right:

• You are running a Linux Mint 17 in VirtualBox on Windows 7.
• Sometimes you hibernate the Windows while the vm is running.
• After wakeup (in a different network) the ownCloud client in the VM persistently fails its DNS lookups.
• The host system can correctly resolve hostnames.
• We don't know whether restarting the client would help because local discovery takes too long.

Questions:

• Can the linux guest correctly resolve hostnames after the host resumes? (maybe you answered this before)

The issue is probably not on the host. Maybe the issue is on the guest. And maybe the issue is in the Qt networking stack.

Qt caches DNS query responses for one minute by default. Something would have to go very wrong with the QElapsedTimer that's used to manage cache lifetime for it to keep using a cached failed lookup forever. Is your guest using Qt < 4.7.4?

[Rocologo]

• You are running a Linux Mint 17 in VirtualBox on Windows 7. -
  CONFIRMED
• Sometimes you hibernate the Windows while the vm is running. -
  Before Hibernating Windows, I close VirtualBox/Linux *- saving
  machine state. I guess this is similar to hibernating*but note
  completely.
• After wakeup (in a different network) the ownCloud client in the VM
  persistently fails its DNS lookups. *- Hmm, not persistently, but
  most of the time. *
• The host system can correctly resolve hostnames. - CONFIRMED.
• We don't know whether restarting the client would help because local
  discovery takes too long.- _YES, local discovery take long, when I
  try__to synchronize _many files. +25.000 or so.

I just realized that I can easily do more testing if I create and extra
folder with a lot of dummy files (from my development) to be
synchronized. I have an idea that the slow synchronisation has something
to do with the number of small files.

On 11/07/2014 09:24 AM, ckamm wrote:

@Rocologo https://github.com/Rocologo Yes, I understand. At this
point I'm just guessing and it seems most likely that this isn't a
client issue but an issue somewhere down the stack. Let me summarize
your issue to see if I got it right:

• You are running a Linux Mint 17 in VirtualBox on Windows 7.
• Sometimes you hibernate the Windows while the vm is running.
• After wakeup (in a different network) the ownCloud client in the
  VM persistently fails its DNS lookups.
• The host system can correctly resolve hostnames.
• We don't know whether restarting the client would help because
  local discovery takes too long.

Questions:

• Can the linux guest correctly resolve hostnames after the host
  resumes? (maybe you answered this before)

The issue is probably not on the host. Maybe the issue is on the
guest. And maybe the issue is in the Qt networking stack.

Qt caches DNS query responses for one minute by default. Something
would have to go very wrong with the QElapsedTimer that's used to
manage cache lifetime for it to keep using a cached failed lookup
forever. Is your guest using Qt < 4.7.4?

—
Reply to this email directly or view it on GitHub
#2323 (comment).

[Rocologo]

I am at work so I forgot to answer the last two questions.

• DNS on the host works all the time. DNS on the guest does not always work. ANd Yes it might be an error in the guest, but this does not explain why syncronisation sometimes fails (time out), when I have get DNS up and running.

You ask if Qt is > 4.7.4 ? Im dont know what Qt is? QuickTime? I dont think I use QuickTime? QElapsedTimer? I dont know what that is?

[ckamm]

About Qt: It's the library we use for networking, among other things. I checked and I think Mint 17 comes with 4.8.6 though.

[Rocologo]

Hi ckamm. OC 1.7.0 was released in the repository, and my OC 1.6.4 was updated to 1.7.0, so now I have to start over to see if I get syncronisation errors when I jump between home and work. I can also see that the discovery function has changed. The client is making a full scan, it took about 1 hour, but I guess thats okay for ~200.000 files / 17 GB. Maybe we should close this thread until I seen if Im getting the error on the new client?

[ckamm]

@Rocologo Ok, I'm closing this one. Please reopen if it happens to you again.

[guruz]

Thanks, closing this for now..

[guruz]

Would have been improved by #2976