Skip to content

level=ERROR msg="error received after stop sequence was engaged" err="leader election lost" #3535

Open

Description

@mxey

When running a controller manager with LeaderElection enabled, shutting down the manager will obviously release the leader lock. However, this seems to still trigger a “leader election lost” error:

level=ERROR msg="error received after stop sequence was engaged" err="leader election lost"

On its own, this is just a nitpick, but the problem is in combination with using the t.Output() writer in your test functions. Tests are not allowed to keep writing to it after the test has finished. You will either get a panic, or might even get a data race detected if you run the test with the race detector.

The problem here is that the manager keeps doing something even after its Start method has already returned. The log is a symptom of that, but IMO the manager should be completely gone once Start returns.

Activity

  1. mxey commented on Jun 25, 2026

    @mxey
    Author

    I think the culprit is in engageStopProcedure where this goroutine is started but nothing waits for it to finish:

    	go func() {
    		for {
    			// Closing in the for loop is required to avoid race conditions between
    			// the closure of all internal procedures and making sure to have a reader off the error channel.
    			closeOnce.Do(func() {
    				// Cancel the internal stop channel and wait for the procedures to stop and complete.
    				close(cm.internalProceduresStop)
    				cm.internalCancel()
    			})
    			select {
    			case err := <-cm.errChan:
    				if !errors.Is(err, context.Canceled) {
    					cm.logger.Error(err, "error received after stop sequence was engaged")
    				}
    			case <-stopComplete:
    				return
    			}
    		}
    	}()
    
  2. liketosweep commented on Jun 25, 2026

    @liketosweep

    I'd like to investigate this if no one is working on it

  3. k8s-triage-robot commented on Oct 21, 2026

    @k8s-triage-robot

    The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

    This bot triages un-triaged issues according to the following rules:

    • After 90d of inactivity, lifecycle/stale is applied
    • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
    • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

    You can:

    • Mark this issue as fresh with /remove-lifecycle stale
    • Close this issue with /close
    • Offer to help out with Issue Triage

    Please send feedback to sig-contributor-experience at kubernetes/community.

    /lifecycle stale

  4. mxey commented on Oct 21, 2026

    @mxey
    Author

    /remove-lifecycle stale

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions