Untrusted device never finishes syncing, very high memory usage

[tomasz86]

@cyplo

I can see there is a lot of filepaths in the log after enabling model debugging, is there a way to automatically anonymise those ? I consider them sensitive and wouldn’t want to post them publicly.

You can try using my sed patterns, although please compare the output and the original to verify that it hasn’t “anonymised” too much in the process, including the actual useful information .

/"[^"]*"/ s//"xxx"/g
/(open|remove).*:/ s//\1 xxx:/g
/(([A-Z]|[0-9])+)-([A-Z]|[0-9])+-([A-Z]|[0-9])+-([A-Z]|[0-9])+-([A-Z]|[0-9])+-([A-Z]|[0-9])+-([A-Z]|[0-9])+-([A-Z]|[0-9])+/ s//\1/g

If you are unfamiliar with sed, just save them to a text file (e.g. sed.txt), and then run sed --file="sed.txt" --regex-extended "syncthing.log".

[imsodin (Simon)]

@cyplo Are any of the devices involved “very old”, as in Syncthing instances which are installed since a long time?

I have a theory: We have FileInfo.RawBlockSize and on .Blocksize() return that if > 0, otherwise protocol.MinBlockSize. When encryption the FileInfo, we set RawBlockSize on the encrypted FileInfo to fi.RawBlockSize + blockOverhead, where fi is the original FileInfo.

Nowadays we should always set RawBlockSize, that’s why I am interested whether the file infos might predate variable block sizes. If they aren’t old, we either miss setting RawBlockSize somewhere or my theory is wrong/incomplete.

PR confirming and fixing the issue with RawBlockSize: lib/protocol: Ensure correct blocksize on enc. fileinfo (ref #7861) by imsodin · Pull Request #7870 · syncthing/syncthing · GitHub

[cyplo (Cyryl Płotnicki)]

@imsodin

@cyplo Are any of the devices involved “very old”, as in Syncthing instances which are installed since a long time?

Most of the devices I’ve reinstalled the OS within the last year, but one Ubuntu laptop and one Android phone can be running same setup, with subsequent syncthing upgrades over the last 3-5 years maybe ?

The device experiencing the problem is quite fresh, so is the only device it is connected to though, only the devices that are in the same synch group but are not synching directly to the problematic device are older.

(also, I might be slower to respond this week as I’m moving house)

[cyplo (Cyryl Płotnicki)]

@AudriusButkevicius

Did you try the encryption feature before it made it into the official release?

I tried it, but it didn’t work for me. I then wiped the untrusted device completely, but the trusted devices I ran this experiment with are still running within the current synch group.

[cyplo (Cyryl Płotnicki)]

@AudriusButkevicius

Would you be ok running a custom dev build with some extra logging to understand where the allocations are coming from?

Yes, as long as I understand what I’m running there, e.g. compiled it from source myself and I can inspect the diff between 1.18 and that version, if that makes sense ?

[imsodin (Simon)]

@cyplo

Most of the devices I’ve reinstalled the OS within the last year, but one Ubuntu laptop and one Android phone can be running same setup, with subsequent syncthing upgrades over the last 3-5 years maybe ?

In that case I am still happy with my hypothesis

Next weeks RC will have the fixes mentioned above.

[cyplo (Cyryl Płotnicki)]

Should I then test the RC when it’s out, send any more info in the meantime , anything else ?

[imsodin (Simon)]

No more info required from my side. And yes, you can use the RC to fix your problem. Could have mentioned before: If you’d want to try immediately, you could use nightly builds: Versions & Releases — Syncthing v1 documentation