Folders paused, but uploading still going on (and stalled download)

I have encountered this problem today. It is still going on right now, and I’m not sure what I can to do fix this. I have tried restarting Syncthing on both sides, but to no avail.

There are two devices involved - D4DZUG and TLFGVK. Both are decent desktop PCs running Windows, but the connection between them is heavily bandwidth restricted. However, despite that they do sync with one another with no issues under normal circumstances.

I’ve been trying to push a few files from D4DZUG to TLFGVK. However, even after pausing all other folders, the transfer is stuck. This is how the situation looks like at the moment.

D4DZUG:

TLFGVK:

image

As you can see, TLFGVK shows 0 B/s download. However, it keeps uploading something to D4DZUG at ~25 KiB/s, even though all other folders are paused. I have tried enabling various debug logging to find out what exactly is being uploaded, but I couldn’t find anything there. Is it possible to check what exactly is being pushed from TLFGVK to D4DZUG?

I have taken goroutine dumps on both devices.

I will be very thankful if you can check them and see if there is anything suspicious there. I don’t think that this is the same issue as https://forum.syncthing.net/t/remote-device-appears-connected-but-synchronisation-is-stuck/17145, because I have cherry-picked the relevant commit, and also here the stalled files are listed on both sides. It is just the transfer itself that is stuck.

You can enable model tracing to see all incoming and outgoing requests.

There’s a truckload of both incoming and outgoing request on TLFGVK from an encrypted folder, many of them waiting to go through since 11min. Given there’s no enc folder in the screenshots, I assume there’s another folder in your setup which uses up all bandwidth.

This is strange. There are no encrypted folders on these two devices. I did test setting up an encrypted folder ~2 months ago, but it was very brief and lasted only a few days until it was removed. No other encrypted folders have been set up on the two since then. Is something broken here?

There was another folder (SR, not encrypted) that was using all the bandwidth, but I paused it together with all other folders except for the one shown in the screenshots. Basically, all other folders had been paused on both devices for at least 10+ minutes, but the GUI was still showing transfer going on. That is when I took the screenshots and opened this thread.

Right, the other way around: Lots of request going out to an encrypted remote device. Only one folder is running, so that matches your description - sorry for the confusion.

I can’t see anything wrong from Syncthing’s side in the goroutines: TLFGVK is sending requests for data to D4DZUG. Looks like the connection is ridiculously slow or stalled.

I’m still a little confused :hushed:. What do you mean by “encrypted” remote device?

Requests go through an encrypted connection:

github.com/syncthing/syncthing/lib/protocol.encryptedConnection.Request(0x1c5cb88, 0xc0005b0500, 0xc0005b0500, 0xc00104bf20, 0x1c53198, 0xc003d61600, 0xc000d8dee0, 0xb, 0xc0016d28d0, 0x2e, ...)

That means it is sending requests to a device on which there is a password in the sharing tab for that folder set.

Yeah, this is what I suspected. There are no passwords set whatsoever here. No folders have passwords set, and no device is marked as “untrusted”. Just to be 100% sure, I have just checked config.xml from both devices - all passwords are empty (i.e. <encryptionPassword></encryptionPassword>).

I suspect that something might have broken when I was testing the still incomplete receive encrypted functionality a few months ago… Is it possible to know which folder the log is talking about?

Weird indeed. Even if at some point we didn’t handle removing passwords (I think that was the case), that should resolve as soon as the connection to that device is dropped at any point. And I think it’s quite unlikely that never happened for a few months.

No way to see which folder from goroutines. However there’s only one running, so it should be clear which one it is.

Hmm, what is the best way to deal with this? Would it be enough to remove the folder on one side, wait for a new share request, and then re-add it? Or, do I need to to remove it on both sides and re-add as a completely new folder under the same path?

The connection between the two devices has dropped many times since I was testing the encryption. There has been at least one database reset on each side too.

Argh, I am confusing too many things today: Nothing wrong about it. Every connection is wrapped into an encryptedConnection, which is a noop if there is no password set.

So back to everything working as expected from the information available, just extremely slow.

1 Like

It’s all right. I’m glad to hear that I don’t need to worry any more :grin:.

Can pausing folders itself be delayed when the connection is slow or limited heavily?

Shouldn’t be, the relevant commands should have context, i.e. be cancellable.

There’s often some minimum quantum that needs to complete for it to cancel though, often one network or disk I/O.

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