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
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 
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…
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…
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