"Ouf of Sync Items" not synchronizing

Support
1

The following bug has appeared since v0.14 or so, and always after I upgrade Syncthing (but not after every upgrade), so I thought I’ll finally post about it. I also think, this is the same problem as these issues:

This has led me to an apt policy of putting the syncthing package on hold (Debian jessie and stretch) and wait for a bit, because the bug seems to disappear after a minor update to the package (I am using https://apt.syncthing.net/ syncthing stable as repository).

So, until yesterday, my three devices were working perfectly using, I think, version 1.1.4. This is the relevant part of the network:

Device_A <-------> Device_B <-------> Device_C

Then, I upgraded Device_A and Device_B to v1.2.0 and, suddenly, I get this (and I’ve seen this problem often and tried all sorts of things, but in the end, waiting for a minor upgrade works best, but it gets annoying):

Screenshot of Device_A pointing to Device_B: device_a

Screenshot of Device_B pointing to Device_A: device_b-a

Device_C was still okay then, but today I also upgraded Device_C to 1.2.0 and suddenly:

Screenshot of Device_C pointing to Device_B: device_c

Screenshot of Device_B pointing to Device_C: device_b-c

If you examine a few of those “Out of Sync Items” files, they are completely fine: They have the proper permissions (“Ignore permission” is enabled on all shares and devices), the timestamps are the same, the MD5 checksums are the same, etc. If you create a new file in a shared folder, it will synchronize, but not the others.

I’ve tried the log flags fs, model, scanner, walkfs, but didn’t find anything unusual.

This happens regularly after a major update, and then after a while, a minor update to the package is released, and the problem goes away.

2

This sounds very interesting to me!

Are you sure, the Out of Sync Items can not arise, because with every major update the database will be “renewed” and things (initial scannings) will just take so long, until the next minor update coincidental is released at this time?

Just an idea, maybe there is no initial scan after a major upgrade.

I have a similar setups Device_A <-------> Device_B <-------> Device_C (Win+Mac+Linux) and did not see that static behaviour like you describe for such a long time. Sure, if 3 devices are scanning their folders, until scanning is done, I see a lot of Out of Sync Items as in your screenshots, but they vanish after a day or so. (Depends on the Foldersizes)

3

You are looking at the wrong thing.

You should look at each of the machines local state, oppose to what A thinks about B and what B thinks about A. It’s more important to look at what A thinks about itself, compared to what B thinks about itself.

4

I’m afraid you’re wrong. I used tcpdump to monitor the traffic between the devices and realized almost nothing is exchanged. Then I saw, that:

  • Device_A displays Device_B is listening on 41722
  • Device_C displays Device_B is listening on 49044

when in fact Device_B is listening on default 22000. If I restart Syncthing, the ports will change to something else, but not 22000.

I just restarted Device_A and Device_C and now Device_B thinks

  • Device_A is listening on 34777
  • Device_C is listening on 50156

They are both listening on default port 22000. Any ideas what is going on here?

Also, all three devices have the addresses of the other devices hardcoded as tcp4://<ip_address>:22000. Usually, when the port ends up to be a different one, Syncthing displays this as “discovered”, as opposed to “configured”, but this isn’t happening here.

5

Configured means you are forcing ports, doscovered means its discovered the ports. Listening happens on port 22000, dialing happens from a random kernel suggested port.

1 Like
6

Yeah, that’s what I said. It’s about what comes after that: The question is, why — given that the address and port is hardcoded – does it

  1. try to connect to the wrong port (41722, 49044, etc.)
  2. when the actual listening port is 22000 and
  3. the wrong port is not displayed as “discovered”, as opposed to “configured”
7

How do you know it’s trying to connect to that port, oppose to being given that port by the kernel when dialing?

You have to understand that TCP requires allocating a port on both sides, and tue source port you are connecting from is usually random.

8

Upgrades mean a complete index resend. Your screenshot shows the devices “syncing” which means they are processing this index resend. If no changes have happened, no changes are transferred either. This is expected.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.