Question
Docker daemon reports 'version mismatch' after failed upgrade and does not roll back automatically
Mira Lane
0 reputation · 11 Apr 2022, 16:46 UTC
148.2K views1
Loading…
0 reputation · 11 Apr 2022, 16:46 UTC
Goal: assess whether Docker Engine should initiate an automatic rollback when a daemon upgrade fails due to a version‑mismatch error.
Constraints: the current behavior requires manual intervention, which can delay recovery and, in a Swarm cluster, jeopardize quorum if a manager node remains offline. There is no documented policy defining the conditions under which a retry should be attempted versus a rollback, nor any mechanism for the daemon to communicate rollback readiness to orchestration tools.
Uncertainty: it is unclear what safety checks (e.g., binary availability, container compatibility) must be satisfied before an automatic rollback is triggered, and how such a rollback would interact with ongoing workloads or Swarm state.
Questions: What specific criteria should trigger an automatic rollback after a version‑mismatch failure? How should the daemon signal rollback completion to Swarm or Kubernetes control planes? Should a manual downgrade be followed by an automated safe‑rejoin procedure for manager nodes?
Docker Engine does not automatically roll back after a failed upgrade that produces a "version mismatch" error. Recovery requires manual intervention.
When the upgrade fails the daemon binary, its libraries or the data directory can be left in an inconsistent state. Attempting an automatic restart or rollback without verifying that the prior binary set is compatible with the existing graph driver and metadata risks storage‑driver corruption and prolonged unavailability.
docker
xddocker version and note the Client and Server API versions and any error text from the daemon logs.rpm -qa --last or dpkg -l | grep docker) to see which components were partially upgraded and whether the previous Engine, containerd and runc binaries are still present on disk.sudo yum downgrade docker-ce or sudo apt-get install docker-ce=).docker node update --availability drain ), confirm that the remaining managers still have quorum (docker node ls), then start the downgraded daemon.docker node update --availability active ) and verify it rejoins the raft.Determine whether the version mismatch is reported only by the client (client‑daemon API skew) or if the daemon itself fails to start or logs a version error. This distinction changes the recommendation: a client‑only mismatch does not require a daemon downgrade.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.