(and this isn't being reset by anything in ../sysctl.conf)..
So, sysctl on boot-up, should be setting max_user_instances to 1024 (which would be fine for us!)
But when I check the running value in the host, it's not 1024, but it's 256:
ubuntu@juju-0298df-0:/etc/sysctl.d$ sudo sysctl -a | grep max_user_inst
fs.inotify.max_user_instances = 256
This is on a VM built entirely by Juju. So something is setting it back to 256 after sysctl.d runs. This is what's limiting our LXD counts
So whilst I understand that asking Juju to mess around with lxd parameters is probably not a great idea, I think something is pushing the lxd parameters down from the default lxd parameters.
This VM is built by Juju, however, we do install the Juju client on it after Juju has deployed.
So I think in our case, I think Andrey's original comment was correct - when the Juju client is installed on a machine, it forces the max_user_instances down to 256 even if they were originally higher:
ubuntu@juju-0298df-0:/usr/lib/sysctl.d$ ls -ltr
total 8
-rw-r--r-- 1 root root 682 Feb 13 21:32 50-default.conf
-rw-r--r-- 1 root root 73 Feb 15 00:20 juju-2.conf
ubuntu@juju-0298df-0:/usr/lib/sysctl.d$ more juju-2.conf
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 256
ubuntu@juju-0298df-0:/usr/lib/sysctl.d$
So should the Juju client snap really be doing this?
Hi both,
Thanks for the feedback. It's probably my ignorance, but I'm still a bit confused.
Our host VM (on GCP) has the following in sysctl.d:
ubuntu@ juju-0298df- 0:/etc/ sysctl. d$ ls -ltr security. conf restrictions. conf hardening. conf privacy. conf messages. conf network- security. conf ipv6.conf
total 52
-rw-r--r-- 1 root root 519 Jan 17 2018 README
-rw-r--r-- 1 root root 506 Jan 17 2018 10-zeropage.conf
-rw-r--r-- 1 root root 1292 Jan 17 2018 10-ptrace.conf
-rw-r--r-- 1 root root 509 Jan 17 2018 10-network-
-rw-r--r-- 1 root root 1184 Jan 17 2018 10-magic-sysrq.conf
-rw-r--r-- 1 root root 257 Jan 17 2018 10-link-
-rw-r--r-- 1 root root 726 Jan 17 2018 10-kernel-
-rw-r--r-- 1 root root 490 Jan 17 2018 10-ipv6-
-rw-r--r-- 1 root root 77 Jan 17 2018 10-console-
-rw-r--r-- 1 root root 2115 Sep 5 21:51 11-gce-
-rw-r--r-- 1 root root 153 Sep 10 19:19 10-lxd-inotify.conf
-rw-r--r-- 1 root root 185 Nov 20 15:14 99-cloudimg-
-rw-r--r-- 1 root root 2064 Nov 20 16:08 99-gce.conf
lrwxrwxrwx 1 root root 14 Feb 13 21:32 99-sysctl.conf -> ../sysctl.conf
Only one of these confs includes max_user_instances:
ubuntu@ juju-0298df- 0:/etc/ sysctl. d$ grep "max_user_" * inotify. conf:fs. inotify. max_user_ instances = 1024
10-lxd-
(and this isn't being reset by anything in ../sysctl.conf)..
So, sysctl on boot-up, should be setting max_user_instances to 1024 (which would be fine for us!)
But when I check the running value in the host, it's not 1024, but it's 256:
ubuntu@ juju-0298df- 0:/etc/ sysctl. d$ sudo sysctl -a | grep max_user_inst max_user_ instances = 256
fs.inotify.
This is on a VM built entirely by Juju. So something is setting it back to 256 after sysctl.d runs. This is what's limiting our LXD counts
So whilst I understand that asking Juju to mess around with lxd parameters is probably not a great idea, I think something is pushing the lxd parameters down from the default lxd parameters.
This VM is built by Juju, however, we do install the Juju client on it after Juju has deployed.
So I think in our case, I think Andrey's original comment was correct - when the Juju client is installed on a machine, it forces the max_user_instances down to 256 even if they were originally higher:
ubuntu@ juju-0298df- 0:/usr/ lib/sysctl. d$ ls -ltr juju-0298df- 0:/usr/ lib/sysctl. d$ more juju-2.conf max_user_ watches = 524288 max_user_ instances = 256 juju-0298df- 0:/usr/ lib/sysctl. d$
total 8
-rw-r--r-- 1 root root 682 Feb 13 21:32 50-default.conf
-rw-r--r-- 1 root root 73 Feb 15 00:20 juju-2.conf
ubuntu@
fs.inotify.
fs.inotify.
ubuntu@
So should the Juju client snap really be doing this?