I restarted St this morning as it hadn’t done anything for a few days but virtually nothing is coming in
Other folders related to this sending end have been downloading so I know there isn’t an issue with the two ends, but specifically with this sync folder. The logs reference this sync, up until I restarted St this morning then no further log entries for this particular folder. Other folders from the sending end is included in the log. But there is no errors or panics. It can’t be permissions as other files have already been written to the same folder.
File is on a 14Tb SATA drive
So is there anything that can be done to get the file to start syncing? There’s no syncthing related disk activity against this file? Infact the date and time stamps are
After pausing both ends made no change I turned on model logging and paused all the other folders and all but the affected remote devices, but it remains syncing. I even tried to shutdown, and that was also ignored twice. But got all this racing up on the screen
I use synctrazor and whilst that gui was showing all paused, when I opened an external browser the folders and devices hadn’t changed (no pauses), so that explains why i’m still getting activity. I was also getting the momentary gui pauses that’s been reported elsewhere.
I tried http://127.0.0.1:8384/debug/pprof/goroutine?debug=2 but I get 404 page not found. debugging is enabled, but I recall I have to do something to get this to work but I can’t recall or find what I need to do. I still have STHEAPPROFILE=1 enabled and making files if that’s of any help, but is probably not the trace you need.
I seem to recall I had to change the variable to STPROFILER=1 then got panic-20200430-002945.reported.log but have restarted synctrazor and paused everything but the one folder. It’s gone to preparing to sync.
My apologies for the last post. It was very late (close to 1am I think) and thus very tired and not thinking straight. Thanks to tomasz86, I have now got it all appearing on the screen. However after adding the variable and restarting the PC the syncthing is now syncing so if any folders stall I can send a trace
What i’m finding is that if all but the one affected folder are paused and St restarted, then the one folder will run and download pretty fast. I then think it’s all fine and resume all the others after a few hours has passed. But at some point later the affected folder will stop working. It’s as if St is overloaded with requests and everything grinds to a crawl (cpu threads = 93). Download speeds on any folder drops to low Mb/s with the affected one at 0 other than an occasional 6 bps.
Also, trying to pause the folders no longer seems to work. They say they are paused but a few minutes later the gui refreshes and there’s been no change.
The trace does contain lots of syncing folders so hopefully there might be something that looks unexpected.
Thanks for having a look. I’ve managed to pause all but one folder so will see if that resumes syncing or just sits there. I sent it because I thought the query folder hadn’t updated in hours.
I have. I’ve gone back to 1.3.4 to see how that compares. I’m trying to constructively explain what i’m seeing and the issues i’m getting and I feel that i’m being disregarded. But looking through other threads, say from the last month others are getting similar problems but they worded their issue in a different way.
I don’t wish the tone of this reply to sound bitter, just exasperated.
This means there are errors while syncing, which is logged and displayed in the web UI together with the actual error message. This error message is what Audrius refers to, i.e. what needs fixing. If it isn’t evident what to do from the error message, please post it here. If there’s new things to sync, Syncthing will do that regardless of the delay mentioned, this delay is just for a retry for the existing items that failed if there is no other changes.
There wasn’t any errors, everything was running as expected, all the other folders were up to date, syncing or scanning.
I just need to try on 1.3.4 just to ensure that it is a 1.5.0 rc2 issue and not a ‘number of folders / IO / something else’ as I know that 1.3.4 worked well for me in the past.
