When trying to pause or resume folders locally using the Web GUI, I sometimes get these i/o timeout errors. What happens is that the GUI shows the folder being paused, while in reality the command has not worked. If I wait for a while, or refresh the GUI, then the folder goes back to its previous state. Then the actual timeout errors pop up.
I am assuming that this is because of other I/O activity going on in the OS, which prevents Syncthing from doing the changes. I wonder whether it is possible to increase this timeout, so that Syncthing would wait longer for the OS to respond.
Please correct me if my reasoning is wrong and there is something else going on here. I have observed this on multiple Windows machines, so the problem is not limited only to a specific device or such.
I think what’s actually happening here is that a config commit is taking time to happen, because as part of the config commit it needs to wait for reconfigured folders to abort doing what they’re doing and things like that. In the meantime you have other config changes queued that are waiting, and those time out on the HTTP side.
I think the only good fix is making sure a config commit always finishes in reasonable time. That’s the intention anyway.
“Queued” config changes from the browser side are bad because each is a complete config replacement and there’s no defined order they will be processed in.
Hmm, I must say that I probably do not understand everything that you have written, but as a user, can I do anything to help with this problem, or rather a fix on the Syncthing’s side is required to deal with this? Right now, I am not doing anything special, just “using” the Web GUI normally, as it is supposed to be used, I guess. I do run Syncthing with low I/O priority to reduce its performance impact on the OS, but I am not sure whether there is any relation between the two.
Are there any specific logging debug options that I should enable to help diagnose this?
The problem is that I cannot just reproduce these timeouts on demands. They occur irregularly, but often enough to be annoying. I would basically need to enable the debug options and run with them until the problem happens again.
