问题
I have a pretty simple userdata script that installs the CodeDeploy agent on ubuntu and then emits a signal to CloudFormation indicating the instance is healthy. My stack is deployed using CloudFormation, which sets up an ASG, LaunchTemplate, TargetGroup, etc. The target instance type is Ubuntu 18.04 (ami-07ebfd5b3428b6f4d AMI) on t3.small instances. I previously had the same problem on a different AMI, but upgrading to ami-07ebfd5b3428b6f4d seemed to fix it temporarily...it worked for several weeks.
Recently, my ASG tried to replace some unhealthy instances, and the new instances didn't come up. On further investigation, I discovered that I was back to having the same issue again - userdata script not firing. The cloud-init.log ends with this line:
2020-03-20 01:23:56,741 - util.py[DEBUG]: Running command ['/var/lib/cloud/instance/scripts/part-001'] with allowed return codes [0] (shell=False, capture=False)
But seems to hang here with no activity in syslog. This file from the log correctly contains by script, and this script executes successfully (without any required interaction) if I invoke it manually.
Changing my CloudFormation stack to instead use t2 instances resolves the issue. I have reserved t3 capacity though, so I need to get back to t3.
Thoughts/ideas anyone?
Update based on comment. Here are the last few lines of cloud-init-output.log:
Setting up apport (2.20.9-0ubuntu7.12) ...
Installing new version of config file /etc/init.d/apport ...
apport-autoreport.service is a disabled or a static unit, not starting it.
Setting up ubuntu-standard (1.417.4) ...
Setting up grub-pc (2.02-2ubuntu8.15) ...
ESC[1;24rESC[4lESC)0ESC[mESC(BESC[1;24rESC[HESC[JESC[1;1HPackage configurationESC[3;2H┌──────────────────────────┤ Configuring grub-pc ├──────────────────────────┐ESC[4;2H│ESC[75C│ESC[5;2H│ The GRUB boot loader was previously installed to a disk that is noESC[8C│ESC[6;2H│ longer present, or whose unique identifier has ch
回答1:
As it turns out, non-interactive mode was asking for interaction. No idea why this was the case, or why subsequently invoking the script manually didn't exhibit the same behavior. The hint was the garbled log message at the end of cloud-init-output.log (thanks @Marcin for the nudge on that).
The fix was to modify the top of the script to look like this:
export DEBIAN_FRONTEND=noninteractive
apt-get update
apt-get -y upgrade
apt-get install awscli python-pip -y
pip install https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-latest.tar.gz
apt-get autoremove
apt-get autoclean
来源：https://stackoverflow.com/questions/60767389/aws-ec2-userdata-script-doesnt-fire-on-t3-instances