Per email thread, Juju needs to ship with expanded details:
> Stephane, I share your concerns around selecting the right knobs and
> testing accordingly but my main concern now is that I feel many people will
> hit this limitation when they deploy bigger charms in containers. Is there
> any way to expedite the work-around testing?
Well, Juju itself could also be bumping those limits, that way only
hosts that do actually run a bunch of big charms will have their limits
bumped rather than everyone who has LXD installed.
You could just ship a /etc/sysctl.d/10-juju.conf file with:
fs.inotify.max_queued_events = 131072
fs.inotify.max_user_instances = 1024
fs.inotify.max_user_watches = 4194304
** Project changed: juju-core => juju
** Changed in: juju
Status: Invalid => Triaged
** Changed in: juju
Assignee: (unassigned) => Richard Harding (rharding)
** Changed in: juju
Milestone: None => 2.0.0
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1602192
Title:
when starting many LXD containers, they start failing to boot with
"Too many open files"
To manage notifications about this bug go to:
https://bugs.launchpad.net/juju/+bug/1602192/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
