Theme

Update refused or failed: could not report its version: exit status 1 ​

The setup program of Syncplify Server! 8.4.0 through 8.8.0, run on an existing installation, stops with:

The update was refused before anything was changed:
staged ss-wrk: could not report its version: exit status 1

Or a self update to 8.8.0 ends with an outcome such as:

The update failed after the new binaries were installed and the node was left
on the new version ... installed ss-webrest: could not report its version:
exit status 1

Nearly always on Windows Server, often on a small virtual machine or one with a third party antivirus.

What the message means ​

Before an update, the updater of those versions started each freshly extracted binary once and asked it for its version, with a budget of fifteen seconds. The first start of a large, freshly written, signed executable is not free: Windows reads the whole file, the antivirus scans it before it may run, and a single busy processor schedules it late. When that took longer than the budget the updater stopped the binary, and on Windows a stopped program reports exit code 1, the same text a broken program would produce. The binaries are fine; the question was asked too impatiently.

From 8.9.0 no packaged or installed binary is run to learn what it is. The setup program and the self update read the versions and checksums the release carries, and the only test of whether the new binaries run on your machine is the real one: the services start and the node passes its health check, with the rollback behind it.

What state the node is in ​

  • "Refused before anything was changed": the node is intact on its previous version. Nothing was stopped, copied or modified.
  • "Failed after the new binaries were installed and the node was left on the new version" (a self update to 8.8.0): the node runs the new version and its services were started by the update, so it usually works. Acknowledge the outcome on the Updates page, then finish what the update could not: run ss-webrest dbcmd --postupdatetasks with the SyngoDB service running, refresh the service definitions with ss-webrest svc install and syngod svc install -s ss-syngod -c <data directory>\cfg-ssrv.yaml, and on Windows recreate the two inbound firewall rules for the Web/REST and worker programs, or simply run the setup program of the same version once more. If anything in this list is unclear, contact support with the update.log file and the ss-update log from the data directory before taking further action.

Get the update through ​

  1. Use the setup program of 8.9.0 or newer. It no longer runs any packaged binary before the update, so the slow first start cannot refuse it, and it carries the fix for every later update the server performs on its own.
  2. If you must install 8.8.0 or an earlier 8.x on that machine, exclude the staging folder from the antivirus's on access scan for the duration of the setup (C:\ProgramData\Syncplify\Server\bin), run the setup, then remove the exclusion. Running the same setup again without the exclusion usually fails the same way: the setup extracts the binaries afresh each time, and the antivirus scans them afresh.

Updates on Linux are rarely affected; the same two steps apply if they are.