Managed etcd cluster membership has been reset, restart with

Error message

Managed etcd cluster membership has been reset, restart without --cluster-reset flag now. Backup and delete ${datadir}/server/db on each peer etcd server and rejoin the nodes

What it means

Not a failure: after --cluster-reset completes and the member list contains exactly this single member, k3s calls signals.RequestShutdown with this message to stop the process. It instructs the operator to restart without --cluster-reset and to have every peer back up and delete its db directory before rejoining the reset cluster.

Source

Thrown at pkg/etcd/etcd.go:361

				if err != nil {
					return false, nil
				}

				if rebootstrap != nil {
					// storageBootstrap() - runtime structure has been written with correct certificate data
					if err := rebootstrap(); err != nil {
						logrus.Fatal(err)
					}
				}

				// call functions to rewrite them from daemons/control/server.go (prepare())
				if err := deps.GenServerDeps(e.config); err != nil {
					logrus.Fatal(err)
				}

				if len(members.Members) == 1 && members.Members[0].Name == e.name {
					// Cancel the process context so that it will shut down.
					signals.RequestShutdown(errors.New("Managed etcd cluster membership has been reset, restart without --cluster-reset flag now. Backup and delete ${datadir}/server/db on each peer etcd server and rejoin the nodes"))
					return true, nil
				}
			} else if e.client != nil {
				// make sure that peer ips are updated to the node ip in case the test fails
				members, err := e.client.MemberList(ctx)
				if err != nil {
					logrus.Warnf("failed to list etcd members: %v", err)
					return false, nil
				}
				if len(members.Members) > 1 {
					logrus.Warnf("failed to update peer url: etcd still has more than one member")
					return false, nil
				}
				if _, err := e.client.MemberUpdate(ctx, members.Members[0].ID, []string{e.peerURL()}); err != nil {
					logrus.Warnf("failed to update peer url: %v", err)
					return false, nil
				}
			}

View on GitHub (pinned to 6ba341e396)

Solutions

Restart k3s without --cluster-reset; the reset node boots as the sole member.
On each former peer: back up and delete /var/lib/rancher/k3s/server/db, then start that server with --server https://<reset-node>:6443 to rejoin.
Verify quorum and workload health after peers rejoin.

Example fix

# after seeing this message on the reset node
systemctl restart k3s   # no --cluster-reset
# on each peer
mv /var/lib/rancher/k3s/server/db /var/lib/rancher/k3s/server/db.bak
k3s server --server https://<reset-node>:6443

Defensive patterns

Strategy: try-catch

Validate before calling

// Automation wrapper: detect completion of a reset before moving on.
if out, err := run("k3s", "server", "--cluster-reset"); err != nil {
	if strings.Contains(string(out), "restart without --cluster-reset") { /* success path */ }
}

Try / catch

// The message arrives via process shutdown: catch it in your supervisor/automation.
if strings.Contains(shutdownReason.Error(), "Managed etcd cluster membership has been reset") {
	// expected: restart service WITHOUT --cluster-reset; then drive peers to wipe db and rejoin
}

Prevention

Automate the two-step reset: run with --cluster-reset once, detect this shutdown, restart clean.
Keep peer runbooks ready: back up + delete db, rejoin with --server.
Never leave --cluster-reset in the systemd unit across restarts.

When it happens

Trigger: Running k3s server --cluster-reset (optionally --cluster-reset-restore-path=<snapshot>) successfully; the completion path detects the single-member condition and deliberately shuts the supervisor down.

Common situations: Planned disaster recovery from a snapshot; resetting a quorum-lost cluster; operators surprised that the process exits after reset.

Related errors

AI-assisted analysis of k3s-io/k3s@6ba341e396 (2026-08-15). Data as JSON: /api/errors/28cc3384d9858d1d. Report an issue: GitHub.