2

I am trying to bootstrap a Centos7 EC2 instance (ami-02eac2c0129f6376b) with bash user-data. Because it runs as root and I need to create a lot of things as the centos user, I use sudo -Hu centos <cmd> many times. Each call introduces a 25 second delay. I have hundreds. What can I do to speed this up?

This is a known issue, but I cannot find any solutions.

I have tried:

  • Add and /etc/hosts entry for my hostname
printf "\n127.0.0.1   %s %s\n" "$(hostname -f)" "$(hostname -s)" | tee -a /etc/hosts
  • Remove myhostname from /etc/nsswitch.conf
sed -Ei 's/\s*myhostname//' /etc/nsswitch.conf

These delays are EXTREMELY painful because I am currently in the Trial and Error phase of building out new user-data scripts.

What can I do?

3
  • Do you not have DNS lookups and hostnames enabled for your VPC? Aug 2, 2019 at 15:22
  • @Michael-sqlbot I curl several resources in my user-data. They have no problem doing lookups. But for some reason, every sudo takes 25 seconds to make the call to the command. Aug 2, 2019 at 20:39
  • Hmmm... does dig $(hostname) work (return the instance's internal IP) and dig -x z.z.z.z (z.z.z.z = instance's private IP) work (return the hostname) or do they time out or return an error? IIRC sudo tries to look up the machine's IP... 25 sec seems like a very long time if this is the problem, but this is the only idea I have. Aug 2, 2019 at 23:01

2 Answers 2

2

While it's better to figure out why sudo is slow and resolve that, you can group your commands together to only call sudo once. Inside your script, you could do something like this:

sudo -Hu centos bash <<EOF
somecommand
somecommand2
morecommands
EOF
2

A bug in the SELinux policy included with RHEL and CentOS 7 caused sudo to wait for exactly 25 seconds on each command. This bug was fixed with the selinux-policy-3.13.1-229.el7_6.10 package. You should create a new AMI with this package (and preferably the whole system) updated.

7
  • I am using - Name: selinux-policy Arch: noarch Version: 3.13.1 Release: 229.el7_6.15 Aug 4, 2019 at 1:53
  • @BrunoBronosky Is that already in your AMI or does your cloud-init update to it on first boot? If it's already in your AMI then the problem may be elsewhere, and it's time to start looking at how your AMI was put together. But that doesn't appear to be the latest CentOS 7 AMI, so you probably should just go ahead and get the latest AMI. Aug 4, 2019 at 1:57
  • My yum update -y updates selinux-policy.noarch 0:3.13.1-229.el7_6.6 to 0:3.13.1-229.el7_6.15 and selinux-policy-targeted.noarch 0:3.13.1-229.el7_6.6 to 0:3.13.1-229.el7_6.15 Do I need to do something after the yum update to get it to take effect? Aug 4, 2019 at 2:01
  • @BrunoBronosky The update needs to be installed before the first run of cloud-init, so you need a new AMI. You should be on ami-089ccd342f0be98ab, or something later, not ami-02eac2c0129f6376b. If you aren't getting that AMI, see this reddit thread. Aug 4, 2019 at 2:02
  • 1
    @BrunoBronosky CentOS 7.7 is being released now. Hopefully they will very shortly get you an updated AMI to work with, which should solve the problem. In any case the wait should not be too long. Sep 19, 2019 at 20:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .