I’ve been playing around with Receive Encrypted folders recently, and I’ve observed this phenomenon of the Web GUI becoming completely unresponsive after adding a new Receive Encrypted folder.
What happens is that I share a password-protected folder from Device A to Device B first, and then on Device B, I accept it using the Web GUI. As soon as that happens, the GUI basically stalls, and it stays like that for a good few minutes. Then, it suddenly comes back to life.
The stalled GUI with the Receive Encrypted folder in the “unknown” state looks like this:
I took two goroutine dumps during the period when the GUI was stalled. I’d be grateful if you could have a look at them when you’ve got some free time and check whether there’s something obvious there.
Both sides run Syncthing 1.20.4 (self-compiled) under Windows 10. I can also add that the hardware on the remote side, where the GUI stalls, is rather weak, although it shouldn’t be that weak. Additionally, the devices are located in different countries, so the connection is obviously affected by the distance between them.
All connections are on IO wait for 2min in the first, and 3min in the second example - including the api one. And in both cases there’s a bunch of config operations stalled since ~2min, and both times a config save is in progress. And there’s goleveldb compaction going on, and long living threads being in a function called compactionError. So my guess would be that there’s continually problematic (slow to broken IO) and adding a folder just brings things down to a crawl. Weird though that it affects both disk and network IO, maybe it’s on OS issue.
Both the OS, Syncthing, its database, and the folders are located on the same 5400 rpm laptop HDD. The Web GUI itself seems quite responsive when dealing with already existing folders, but I guess these slowdowns can be expected then…
I don’t remember the GUI reacting that slowly when we were setting up the other folders before, so I though that there could be something related specifically to Receive Encrypted. This isn’t the case here, right?
For that we’d need info on the javascript to see where it’s hanging. I don’t know by heart, but maybe it’s waiting for the API to acknowledge a config change and thus freezes. Would be a bit unexpected though.
Anyway I wouldn’t exclude that someting is wrong here. Both the slow IO in the short term, but especially also leveldb compactions going on since 475/497min seem more like major issues than just slowness to me. Also the leveldb compaction errors don’t sound good. Disk is healthy?
Supposedly “healthy”, although it’s at least 10 years old. This is an old laptop that is now used basically as a backup/file server (= running Syncthing and performing some administrative tasks from time to time), and there’s not much going on on it other than that. It was probably beaten up in the past quite heavily when it was still used as an actual portable computer though.
I’ve done a surface test with an HDD diagnostic tool and everything came out healthy with no slowdowns or bad sectors and such, so I’d say the HDD condition appears to be fine overall.
Are the leveldb compaction errors something to be much worry about? When it comes to Syncthing and the synchronisation itself, we haven’t observed any abnormal behaviour so far, and the machine has been running like that for ~1.5 years now.
I don’t know really. If it works generally, just slowly, and only freezes for a while on adding a new folder, that might just be the speed that machine can work at. Still probably worth rechecking if those compactions ever finish. And a 10 year old HDD used in a laptop dying wouldn’t surprise me, and Syncthing tends to be pretty good at finding hardware problems (I’d guess at least as good as SMART ).
).