repeated hung at 97, 98, 99%

I have a simple two system setup. One is set for send only, and the other receive only. After about 1-2 days of activity the sending machines will report syncing around the high 90% range and it never completes with ~2-30 files listed. The receiving end has no errors or indication it is out of sync.

New files continue to sync. Most of the time all files are in-sync (verified with md5sum on each end, no extra files on either side). At times a few files are missing on the receiving end.

In all cases /rest/db/completion reports 100 for completion.

To correct I need to remove index-v0.14.0.db and then restart with: /rest/system/restart

After that it syncs up any missing files and reports “up to date”.

Is /rest/db/completion the correct API call to check on the sync status? It does not appear to be correct in some cases, and if correct the GUI is not correct in many cases.

How do I get the same % reported from the API that the GUI displays? I’ve read through the API docs and cannot locate it. I’m assuming this is a computed value.

Why is this hanging when both sides are in sync?

Why is this hanging when a few files are out of sync?

In both cases, the number of pending files is much greater than what is missing.

Is removing the index and restarting the only fix?

Thanks.

1.27.11 on both ends. Linux ARM is the sender, MacOS the receiver.

Update rest/db/remoteneed is reporting files out of sync that are in sync. How do I force a recheck to clear this vs. removing the index and restarting on the sending end.

Thanks.

I’m not sure what’s going on but I’ll do my best. Some questions:

Have you (auto) upgraded to the current version of Syncthing?

What is CPU utilization like on the ARM side?

Is the storage on either the Send Only or Receive Only side connected over the network or over USB?

Is any of the storage nearly full?

Is it possible that a process is hanging onto the files that haven’t completed?

If you wait ten minutes with no files changed, what happens then?

EDITED TO ADD TWO MORE QUESTIONS:

Are these devices connected over a LAN, WAN, VPN, or some other way? Is a Relay involved?

Yes, autoupdated both ends to 1.27.12

CPU util never above 25% on any of the 4 ARM cores.

Network connected. Recv is ethernet, send is wifi. Same LAN, no WAN, VPN, etc…

Storage is not nearly full.

Hanging onto files that haven’t completed. That would be my guess, but if I check the list of files reported as out of sync, they are actually in-sync (md5sum verified, I’ll check time stamps next time).

I can wait ten min or an hour, nothing changes. New files continue to get sync, files listed as out of sync are in-sync. In the 10 or so times I’ve seen this, I’ve only had once an issue where the files were not in-sync.

No relay that I’m aware of.

This is unlikely to involve a Relay — open up the Remote Device in the Syncthing GUI on one side. If it says anything including “LAN”, there’s no Relay. If it says “Relay,” you know what that means :smile: .

A process holding onto those files seems like the most likely culprit to me.

TCP LAN

1 Like

The Relay issue was a long shot on my part anyway. Thanks for answering all my questions so well — sorry I couldn’t be more helpful.

For now my hack is to call:

/rest/db/scan, then poll for /rest/db/completion == 100

if completion == 100 and if there are files listed older than 10 min from /rest/db/remoteneed, then I remove the index and then call rest/system/restart.

1 Like

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