I have an (old, slow) notebook computer that is part of my syncthing group that goes to sleep when idle for a few minutes. Upon waking, in the default configuration, syncthing completely restarts - completely hammering the CPU and disk for upwards of 10 minutes before settling down to noise-level resource usage.
As a test, I’ve changed the config on this machine to set “restartOnWakeup” to false which cuts the time it takes to settle down in half and it appears to do so more gently as well.
My question: is there any danger (risk of data loss particularly) in leaving this set to false?
I’m also using syncthing-inotify, if that makes any difference.
No, you’re fine running without the restart on wake. The purpose of it is to recover faster and more correctly from the case where a laptop has been folded up, moved to somewhere entirely different and then woken up. In that case we may need to rerun UPnP discovery, announce new IP numbers, etc.
I’m going to try turning it off on my (often network-warping on suspend) laptop and see how it goes. Would it make sense to just trigger the network discovery stuff on wake rather than restart, to save rescanning local folders, and then drop the config option?
I’d like to revive this topic, quite a while passed since it was brought up, but it is still very relevant.
As already noted, on laptops that do “travel around” and need the network refreshments, the full restart is quite a battery eater.
I failed to find an issue tracking this on GitHub, if it is the case, we should open one up for it to be somewhere on the road map.
Also, I find it peculiar the the reasoning behind the restart is networks. I was sure it is due to file-watches, possibly disconnected drives, etc. If that’s not a problem, cool.
So I find it hard to see why networking is. Laptops often switch networks without sleep-wake cycle, and syncthing seemingly handles it well without restarts…
I suggest disabling it and trying a few situations. This might not be necessary any more as we have fairly reasonable caching and timeout handling of discovery and so on.
I don’t see any potential for data loss. The issues it were intended to solve were essentially outdated local discovery data, outdated global discovery data, outdated view of NAT mappings, if I remember correctly.
Of those I think both local and global discovery should be fine already as is, and if not we do now have the capability to do soft restart of those internally. NAT mappings I don’t know, but it’s timer based and presumably the timer for renewal should fire directly on wakeup (if we’ve been sleeping long enough) and things should be good.
I disabled it on my laptop and I never had a problem since I disabled it over a year ago I think. Reconnects may need a little bit longer in some cases but better some minutes without connection to all devices than eating a lot of battery.
The good consequence of disabling restartOnWakeup is that ST won’t reset the Paused devices on each wakeup. Currently abroad with my laptop and being charged ~60€/GB once I reached my free 3GB quota by my gsm+isp provider, I found this feature very useful, as the laptop goes to sleep after 1/2h when on battery.
Was storing Paused status for devices in the config.xml ever be an asked improvement ? This would preserve status even on restart. And would an Action/Pause (ie. this device or all remote) make sense ?
Whatever, the more I use ST, the more I love. A chance we have Jakob, Audrius and all other devs
