Cluster update stays at the last node: the second node never updates

You started a cluster update from the Updates page of the SuperAdmin UI. The first node updated, passed its health check and shows the new version. The Updates page then moved on to the last node ("Cluster update: node 2 of 2" on a pair) and nothing has happened since: that node still shows the old version, the Cluster page reports that the nodes run different versions, and Apply now on the node answers:

An update is already in progress. A cluster update pass is running.
Per node actions are available again once it finishes.

This page applies to Syncplify Server! 8.4.0 and newer, the versions that update themselves. For the procedure the cluster follows, see Keeping the server current in the manual.

Nothing is broken, and nothing is half done

The node that waits has not started its own update: its services run the old version untouched, nothing is half applied, and a cluster that runs two versions while a pass is in progress is a supported state. Do not restart services and do not reboot either node. Both would only cost you sessions; neither moves the update along.

Read what the node is waiting for

Open the Updates page and expand the card of the node that waits. It states the reason, which is one of three.

It waits for the node to become idle

The card says the node is busy and counts sessions, transfers or open R2FS files. The pass was started in when idle mode: the node refuses new logins (it is drained) but lets every existing session finish, and it never terminates a session on its own. On a busy SFTP node, or with a client that keeps its session open with keepalives, this can take a very long time.

You can keep waiting, or switch the node to Apply now, which gives open transfers the grace period of the update policy (ten minutes by default) and then terminates the remaining sessions:

1. On the card of the waiting node, choose Apply now instead. The update it already holds is switched to Apply now; the pass continues.
2. If the card offers no such button (see the third case below), cancel the pass first and then use Apply now on the node.

It waits for the update lease held by the first node

The card says the update lease is held by the node that already finished. Nodes update one at a time, and each node keeps a note of who holds the lease. On a node that runs 8.4.0 through 8.8.x that note is cleared when the release message from the first node arrives, and otherwise expires on its own 45 minutes after the first node stopped for its update. So the node proceeds by itself within that time. If you would rather not wait, cancel the pass and use Apply now on the node, as in the next section.

The node holds no waiting update at all

The card shows the Apply buttons and the message that a pass is running, with no waiting update on the node, and the last action on the card says the waiting update was dropped: for example the release was not eligible for the node at that moment, or the staged files were gone. On a node that runs 8.4.0 through 8.8.x the pass then stays running with nothing left to run it, which is exactly the situation this page describes.

From 8.9.0 a node whose waiting update is dropped halts the pass at once, with the reason, so the pass never stays silently running; and the maintenance standing verified when the pass started covers every node for the whole pass, so a licensing service that cannot be reached for a minute halfway through no longer drops the last node's update.

Finish the update

1. On the Updates page of any node, choose Cancel cluster update. It only drops the waiting update on the node that has not started, and lets that node accept logins again; the nodes already on the new version stay there. The cancel is allowed once the first node has released the lease, which a node on 8.8.0 or newer does as soon as it finishes. If it is refused because the first node still holds the lease (a first node on 8.4.0 through 8.7.x releases it only at its next restart), wait: the lease expires 45 minutes after that node stopped for its update, and the cancel is accepted from then on.
2. Fix the reason, if the last action named one (renew or extend the maintenance plan if the release was not eligible; check that the node can reach the release channel).
3. Either start a new cluster update with Apply now (the nodes already on the new version are counted as done and the remaining node is updated), or open the remaining node's card and choose Apply now there.
4. Open transfers get the grace period, the remaining sessions are terminated, the node updates and runs its health check. The cluster then shows one version everywhere.

From the command line

On 8.9.0 and newer, ss-webrest update status on the waiting node prints a waiting on line with the node's verdict (busy with the session count, waiting for the lease and who holds it, settling, and the others) and a cluster pass block with the order of the nodes, the lease holder or who released it last, every node's progress, and where a halted pass stopped and why. Run it as administrator on Windows (from C:\Program Files\Syncplify Server!) or with sudo on Linux (from /opt/Syncplify/Server/bin).

If you contact support

Send a screenshot of the Updates page with the waiting node's card expanded, the update policy, the Cluster page, the update-state.json and update.log files from the data directory of the node that finished, and the ss-webrest log of both nodes covering the hour of the update. On Windows the data directory is C:\ProgramData\Syncplify\Server; on Linux it is /opt/Syncplify/Server/data.