This was fixed a long time ago as part of bug 892552. Bug 1579593 still
remains.
** Changed in: juju
Milestone: 2.1.0 => None
** Changed in: juju
Status: Triaged => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
** Changed in: juju (Ubuntu)
Assignee: (unassigned) => Menno Smits (menno.smits)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1654116
Title:
Attempts to write leadership settings when not
** Also affects: juju-core
Importance: Undecided
Status: New
** Changed in: juju-core
Milestone: None => 1.25.7
** Changed in: juju-core
Status: New => Triaged
** No longer affects: juju
** Changed in: juju-core
Importance: Undecided => Medium
--
You received this bug
It's worth noting that this is unlikely to be a problem with Juju 2.0 as
we no longer have all the agents in each environment logging to
rsyslogd. Juju agent logs are now sent to the controller machines over
the Juju API and are stored in MongoDB.
This is really just a Juju 1.25 issue. Retargettin
This sounds like there needs to a tweak to the rsyslogd process limits
to allow more open file handles and/or a change to the maximum number of
connections in rsyslogd's config.
** No longer affects: juju-core
--
You received this bug notification because you are a member of Ubuntu
Bugs, which i
Summarising what we know so far and adding a few more details:
1. We understand why mongo was continually restarting. jujud currently
restarts mongo every time it starts so every time jujud panicked (~
every 10s), upstart would restart jujud and jujud would restart mongo.
This explains the observe
