Why would running sudo in an LXD container be so slow?

sudo taking as much as 25 seconds to execute a simple command. As far as I can make out its the sudo process which is deadlocking rather than the su’ed process.

time sudo cat /etc/sudoers.d/90-cloud-init-users

Created by cloud-init v. 22.1-4.el8 on Tue, 16 Aug 2022 14:15:05 +0000

User rules for myuser

myuser ALL=(ALL) NOPASSWD:ALL

real 0m25.055s
user 0m0.012s
sys 0m0.015s

Sounds like it could be a DNS issue.

Not DNS I’d added the hostname into the /etc/hosts as 127.0.1.1 :wink:

Instant once I changed it to 127.0.0.1

So now the question is why doesn’t LXD honour the 127.0.1.1 loopback address?. Assumings its not some artefact because I’m running RHEL 8

Some software (e.g., GNOME) expects the system hostname to be resolvable to an IP address with a canonical fully qualified domain name. This is really improper because system hostnames and domain names are two very different things; but there you have it. In order to support that software, it is necessary to ensure that the system hostname can be resolved. Most often this is done by putting a line in /etc/hosts containing some IP address and the system hostname. If your system has a permanent IP address then use that; otherwise use the address 127.0.1.1.

I’m not sure what you mean.

This is an example of sudo running quickly in an images:ubuntu/focal container:

root@cbuild:~# cat /etc/hosts
127.0.1.1	cbuild
127.0.0.1	localhost
::1		localhost ip6-localhost ip6-loopback
ff02::1		ip6-allnodes
ff02::2		ip6-allrouters

root@cbuild:~# time sudo whoami
root

real	0m0.046s
user	0m0.009s
sys	0m0.023s

That /etc/hosts entry is created by cloud-init by default and its updated every boot according to the cloud-init.txt file.

https://github.com/canonical/cloud-init/blob/main/doc/examples/cloud-config.txt

#    localhost:
#      This option ensures that an entry is present for fqdn as described in
#      section 5.1.2 of the debian manual
#      http://www.debian.org/doc/manuals/debian-reference/ch05.en.html
#
#      cloud-init will generally own the 127.0.1.1 entry, and will update
#      it to the hostname and fqdn on every boot.  All other entries will
#      be left as is.  'ping `hostname`' will ping 127.0.1.1
#
#      If you want a fqdn entry with aliases other than 'hostname' to resolve
#      to a localhost interface, you'll need to use something other than
#      127.0.1.1.  For example:
#        127.0.1.2 myhost.fqdn.example.com myhost whatup.example.com

Still not following why this is an LXD issue?

Never said it was I just want to fix it… :wink:

I’m not clear that it has any involvement with it.

OK I’ve found a work around… It appears that the EL8 capabilities is not permitting ping request from the non-root user of the LXD container.

Thus:-

[atcore@avshard-APLPRD-22081612-0 ~]$ ping 127.0.1.1
ping: socket: Operation not permitted

This is due to the net.ipv4.ping_group_range on my EL8 instance to 65534 as LXD uses UIDs far greater than that.

So the following command fixes the issue inside the container…

sysctl -w "net.ipv4.ping_group_range=0 429296729"

For the time being my work around is to add new write_files to the cloud-init for the instances…which creates the following file:-

/etc/sysctl.d/66-ping_group.conf
net.ipv4.ping_group_range=0 429296729

And an additional runcmd so its enabled on first boot:-

    bootcmd:
     - [ cloud-init-per, once, sysctl, --system ]

ping and sudo work fine after that…

1 Like

OK I refined I and changed the kernel parameters within the instance to allow ping group access…

I’ll add that file creating into my cloud-init / instance profile