Getting rid of restarts

Hey folks,

I’m going to document some of the limitations that I’m running up against as I code Heartbeat. These are features that we will be helping to fund with in the initial run, starting with getting rid of restarts:

Currently every update to the configuration requires a restart. This makes it very difficult for scenarios where the configuration could be changing very often (e.g., every few minutes) as it slows down the user experience, and complicates client code.

Jakob, Audrius, how complicated do you think this is. Audrius, I’d love this to be the first thing we work on — if Jakob is cool with it also, could you estimate it for me so we can get cracking?

CC @AudriusButkevicius @calmh


I guess @calmh has laid the first stone here where the config can now advertise that it has changed.

The hardest problem I see is that we launch a random number of go routines which work independently on some specific task, and signalling them to exit and clean up is the hardest part, as they might be in the middle of something…

For example, what happens if you remove a folder mid-way through a scan?

I am pretty sure that there would be all sorts of exciting edge cases here :smile:

Yeah, I started on this and there are some tricky aspects. Mainly to do with deciding when we need to drop and reconnect devices, when we need to drop and refuse new connects from them, moving a folder from read-write to read-only etc. In most cases a change is going to be almost like a mini-restart in that we must stop scans/pulls, drop connections to affected devices etc anyway.

I think the way forward is to do it piece by piece. Like, teach the GUI to restart itself on a port change. Then there’s no need to restart for that config change. Then do the same for enabling/disabling UPnP. Then for adding a new folder, etc.

(@AudriusButkevicius as a dev note here, I’ve started to make things follow the Serve/Stop interface similar to net/http and compatible with suture, which does make things easier to both start and stop deterministically, and also recover from failures.)

This would require some transition period for the android app, because there are a few things that I change in the config before a restart (most importantly announce server IP, ignorePermissions and lenientMtimes).

A restart will still work of course.

Yeah, I’ll just keep a look on it as it evolves.

Some years passed and I am wondering if making changes in the config still requires restarts?

Sorry for resurrecting this, but back in 2014 I lost interest in Syncthing because of this particular limitation.

For most actions no.