Multiple units told they are leaders

Bug #1723184 reported by Jacek Nykis on 2017-10-12
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
juju
Undecided
Unassigned
juju-core
Undecided
Unassigned

Bug Description

In my environment I had 5 out of 8 units end up with hook errors.

On closer inspection I noticed that all failed units wrongly thought they were leaders and were trying to "leader-set" which was failing.

Once I run "juju resolved" on all affected units they worked fine.

I could not find anything interesting in the logs.

This is the 2nd bug I noticed recently that affects leadership election so they may be related. The other is bug 1721159.

juju 1.25.13
Ubuntu 14.04.5 LTS

Junien Fridrick (axino) wrote :

I have seen kind of the same thing just today, on a fresh 2.2.4 (<24h) model :

2017-10-12 19:28:26 INFO juju-log leader-elected fired. This unit is the new leader: foo/3
2017-10-12 19:28:26 DEBUG leader-elected ERROR cannot write leadership settings: cannot write settings: not the leader
[...]
2017-10-12 19:28:26 DEBUG leader-elected subprocess.CalledProcessError: Command '['leader-set', 'leader_id=foo/3']' returned non-zero exit status 1
2017-10-12 19:28:26 ERROR juju.worker.uniter.operation runhook.go:107 hook "leader-elected" failed: exit status 1

tags: added: canonical-is
description: updated
John A Meinel (jameinel) wrote :

can you describe the charm where you're seeing this? and if there are steps to reproduce?

Junien Fridrick (axino) wrote :

It's our good friend ubuntu-repository-cache, same as in the linked bug. It's one of the rare (only ?) charm that actively uses leadership / has leader-* hooks, which could explain why we're seeing leadership problems only with it.

No step to reproduce as far as I'm aware, unfortunately.

I guess I can resolve the hook error and enable TRACE debug on that env, and wait for a repro ?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers