Problems Running Syncthing

When the user installs your package.

Well I think this thread shows that the problem is not about “pristine” installations, but only matters when there is already an existing configuration, that was touched by a more recent Syncthing binary at some time.

Right. But the user is installing your package. They do that because they want what it provides. Since you allow auto upgrades, the package implicitly provides a random version of Syncthing. The one thing you can’t allow to happen is that a reinstall becomes a downgrade. So providing the latest version at install time seems reasonable.

In fact, looking at what happens, a standard Syncthing will auto upgrade immediately on startup when it’s not been prohibited from doing so. So in effect you are already doing this, just not explicitly. So whatever binary you’re bundling, as soon as we’ve released something new that’s no longer what the user gets when they install, even if they elect to disallow upgrades when they first get to the GUI.

1 Like

Okay, agreed. But I wouldn’t count on being able to grab the latest version. If there is already a binary in the location we would be overwriting, and it is not older than the one we have bundled, it should just be left untouched and possibly do its auto-upgrade thing when started the next time.

I know the people at SynoCommunity won’t welcome that approach. They have a lot of framework stuff in place to build Syncthing and even Go itself when creating the package, instead of just bundling a released binary. The fact that Syncthing is allowed to auto-upgrade at all is probably because they trust that the internal updater will pick a compatible replacement binary matching the platform, and authenticate it as well.

That’s true for a “standard” Syncthing, yes. But I’m still talking about the unfortunate situation where the (re)installation meets an existing config from a previous but higher-versioned binary.

What I want to achieve is actually just what you describe. Just that it bails out trying to read the future config before the upgrade check right now. Instead it should read as much of it as possible to see whether upgrades were disabled in there, and only if autoUpgradeIntervalH == 0 it should fail (with a better explanation). That’s what would fix the failure mode experienced in this topic with SyncTrayzor.

For the SynoCommunity package, the main fault is overwriting an existing binary with an older version without comparing versions first. We need to mirror something like what SyncTrayzor does to mitigate that.

1 Like

That’s entirely inconsistent: Either you care about distributing your custom built, perfectly suiting Syncthing binary, or you let it auto-upgrade. Using a custom built thingy and letting it auto-upgrade makes no sense.

I don’t think Syncthing should do any half reading like that: Either config is usable → go ahead, or it’s not → error. If a package allows auto-upgrades and bundles Syncthing, it’s entirely sensible to make it upgrade when installing the package and encountering a newer config (or better yet, package detects that Syncthing was newer before).

Especially since Syncthing will auto upgrade within seconds of initial package installation, so the user will almost never be running the shipped binary… I said “standard Syncthing” but I don’t mean just our builds - the synology shipped binary will also do this.

I think part of the problem here is that the error message is too technical for the average user to know what to do next (as clearly shown in this topic). In other words, they understand that Syncthing is unable to start, but they’ve got no idea how to fix it.

The solution mentioned in the error message itself, i.e. telling the user to do -allow-newer-config isn’t really an option, because the user still has got no idea where to actually use the flag. The alternative is to go and manually delete/modify the config file, which is problematic too, because the average Windows user doesn’t even know what %LOCALAPPDATA% is.

It would be nice if SyncTrayzor (and other wrappers) had a newbie-friendly solution to either automatically fix the problem or simply ask the user whether they are OK with downgrading their previous config, and then proceed if the user agrees.

That’s because of the historic necessites to get anything built for DSM at all. The multitude of CPU architectures used in Synology’s DiskStations is usually handled by having a cross-compilation toolchain for each model and OS version combo. The generic approach for any C-based software is to cross-compile it using the Synology-supplied toolchain.

For Go programs, they first compile a host-native Golang toolchain. It could just as well be documented as required on the developer’s host, or included in the build Docker image. But it’s built from source for trust or whatever reasons, maybe to allow cross-compiling Golang for use on DSM as well? To generate Go binaries, they hardcode a mapping of DSM architectures to GO_ARCH settings, then use Go’s cross-compilation skills.

I guess besides mimicking the cross-compilation of all other SynoCommunity packages, it must be about trustability and / or having a reproducible build process to not rely on whoever built the “official” binaries. Including their choice of platforms to provide binaries for at all. Since the authenticated source code contains the procedure used to verify and authenticate updates, that leaves the chain of trust intact.

The other possibility would be to record digests of each platform’s binary release as root of trust and download those files directly to pack into the different SPK architecture packages. I can see how one could be skeptical regarding long-term availability of the binary releases and needing to depend on all expected architectures being actually part of the release. Of course the same limitations apply to Syncthing’s internal updater.

But I’m getting a bit off topic I suppose. SynoCommunity works like it does, but this usability problem popping up without user action and without a way to diagnose / fix it should be addressed with the simplest possible means.

It’s even much more complicated on Synology’s DSM platform. You can’t just “run” Syncthing from a terminal. Getting to the terminal itself is a nontrivial task and only gets you an “admin” shell. Switching to the correct user account and setting up the environment like HOME path and Syncthing’s --home flag in addition all needs to be done manually.

Again, asking the user is completely out of the question on Synology. There is just no GUI at all unless you log into a browser session, and even during an upgrade “wizard” the user interaction possiblities are severely restricted. So whatever happens there must be automatic or the user will be left completely oblivious. That’s quite a different situation from SyncTrayzor’s installer in that regard. The common factor is just managing a bundled, but auto-upgrading syncthing binary.

Well it reads the config version currently, so there’s some precedent here.

In my perfect world I’d just like to pass a flag when I first run Syncthing for a given user (ie when I copy Syncthing into a user’s AppData), which makes it auto update there and then.

(Note that this is first run, not install time. Install time has all sorts of complications, not least that the user doing the installation might not be the user who runs Syncthing, and I don’t want to be doing things with downloading binaries from the internet when running elevated.)

2 Likes

Re synology toolchain:
I don’t need an explanation as to why someone would want to make a custom build. I am a tiny bit involved in debian - there’s a thousand more reasons there (good and less so) why it’s built in a custom way. My entire point is that doing that and not disabling auto-upgrades makes zero sense. And if you disable auto-upgrades, the entire discussion we are having here becomes moot.

That’s almost there: syncthing --upgrade will to that, except that it will exit after upgrading. So you first start would be syncthing --upgrade && syncthing serve.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.