EC2用户数据脚本在Centos7 AMI上运行非常慢

kadbb459  于 2023-01-13  发布在  其他
关注(0)|答案(1)|浏览(191)

每次用户数据脚本接触来自AWS Marketplace的centos 7 AMI上的磁盘时,似乎都有25秒的延迟。
这是我的剧本:

#!/bin/bash -ex
echo "[TIMER] START $(date +%s.%N)"
current_user=$(whoami)
echo "Running as: $current_user"
sudo id -u myuser &>/dev/null || sudo useradd myuser
echo "[TIMER] CreatedUser $(date +%s.%N)"
time sudo yum update -y
echo "[TIMER] Yum Update $(date +%s.%N)"
sudo mkdir -p /opt/myuser/resources
echo "[TIMER] Create /opt/myuser/resources $(date +%s.%N)"

sudo bash -c "cat > /etc/systemd/system/my-service.service" <<EOF
[Unit]
Description=My Service
After=network-online.target

[Service]
User=myuser
Group=myuser
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/bash -ex -c 'echo "Hello World"'

[Install]
Alias=my-service
WantedBy=default.target
EOF

echo "[TIMER] Make my-service.service $(date +%s.%N)"
sudo chmod 644 /etc/systemd/system/my-service.service
echo "[TIMER] Chmod $(date +%s.%N)"
sudo systemctl daemon-reload
echo "[TIMER] daemon-reload $(date +%s.%N)"
sudo systemctl enable my-service
echo "[TIMER] enable $(date +%s.%N)"
sudo systemctl start my-service
echo "[TIMER] END: my-service $(date +%s.%N)"

我启动这个AMI的一个c5.large,并使用上面的代码作为我的userdata脚本:https://aws.amazon.com/marketplace/pp/B00O7WM7QW
计时器结果:
x一个一个一个一个x一个一个二个x
如果向右滚动我的ASCII表,您可以看到mkdirchmoduseradd等简单命令需要25秒。
编辑:
/etc/hosts的含量

$ hostname
ip-172-31-40-213.us-west-2.compute.internal
$ cat /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

/var/log/messages中的示例日志,systemd日志显示创建sudo会话需要25秒:

Jan  9 23:50:32 ip-172-31-35-166 cloud-init: + echo '[TIMER] Make my-service.service 1547077832.899069408'
Jan  9 23:50:32 ip-172-31-35-166 cloud-init: [TIMER] Make my-service.service 1547077832.899069408
Jan  9 23:50:32 ip-172-31-35-166 cloud-init: + sudo chmod 644 /etc/systemd/system/my-service.service
Jan  9 23:50:32 ip-172-31-35-166 systemd: Removed slice User Slice of root.
Jan  9 23:50:32 ip-172-31-35-166 systemd: Created slice User Slice of root.
Jan  9 23:50:32 ip-172-31-35-166 systemd: Started Session c3 of user root.
Jan  9 23:50:57 ip-172-31-35-166 cloud-init: ++ date +%s.%N
Jan  9 23:50:57 ip-172-31-35-166 cloud-init: + echo '[TIMER] Chmod 1547077857.946078493'
Jan  9 23:50:57 ip-172-31-35-166 cloud-init: [TIMER] Chmod 1547077857.946078493

journalctl日志显示了可能的问题:

Jan 09 23:50:32 ip-172-31-35-166.us-west-2.compute.internal cloud-init[1197]: + echo '[TIMER] Make my-service.service 1547077832.899069408'
Jan 09 23:50:32 ip-172-31-35-166.us-west-2.compute.internal cloud-init[1197]: [TIMER] Make my-service.service 1547077832.899069408
Jan 09 23:50:32 ip-172-31-35-166.us-west-2.compute.internal cloud-init[1197]: + sudo chmod 644 /etc/systemd/system/my-service.service
Jan 09 23:50:32 ip-172-31-35-166.us-west-2.compute.internal systemd[1]: Removed slice User Slice of root.
Jan 09 23:50:32 ip-172-31-35-166.us-west-2.compute.internal sudo[13392]:     root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/chmod 644 /etc/systemd/system/my-service.service
Jan 09 23:50:32 ip-172-31-35-166.us-west-2.compute.internal systemd[1]: Created slice User Slice of root.
Jan 09 23:50:32 ip-172-31-35-166.us-west-2.compute.internal systemd[1]: Started Session c3 of user root.
Jan 09 23:50:57 ip-172-31-35-166.us-west-2.compute.internal sudo[13392]: pam_systemd(sudo:session): Failed to create session: Connection timed out
Jan 09 23:50:57 ip-172-31-35-166.us-west-2.compute.internal sudo[13392]: pam_unix(sudo:session): session opened for user root by (uid=0)
Jan 09 23:50:57 ip-172-31-35-166.us-west-2.compute.internal sudo[13392]: pam_unix(sudo:session): session closed for user root
Jan 09 23:50:57 ip-172-31-35-166.us-west-2.compute.internal cloud-init[1197]: ++ date +%s.%N
Jan 09 23:50:57 ip-172-31-35-166.us-west-2.compute.internal cloud-init[1197]: + echo '[TIMER] Chmod 1547077857.946078493'
Jan 09 23:50:57 ip-172-31-35-166.us-west-2.compute.internal cloud-init[1197]: [TIMER] Chmod 1547077857.946078493

谷歌搜索更多,我发现:https://github.com/systemd/systemd/issues/2863
这个问题已经在systemd的更新版本中得到了修复,但是AWS EC2上的centos附带了systemd 219版本,我无法自己更新它。有什么建议吗?我可以放置一些配置来避免这个问题吗?我可以删除userdata脚本中的 * 大多数 * sudo示例,但我确实需要它来完成以下任务:

sudo -H -u myuser bash -ex <<EOF
  ... commands
EOF

FWIW Amazon Linux 2随附了相同版本的systemd,但未表现出此行为。

zz2j4svz

zz2j4svz1#

Redhat的链接中注明了问题和解决方案:https://access.redhat.com/solutions/5692661
总之,在userdata脚本中以sudo形式运行命令是不正常的,因此默认策略是不允许这样做,这会导致在尝试运行pam_systemd时延迟25秒,并由于dbus 25秒超时而超时。
在我的例子中,我试图运行su <user> -c "command"。我的错误是通过运行journalctl -b发现的(-b代表当前 Boot 会话)。您可以找到相关的错误日志,如:

pam_systemd(su:session): Failed to create session: Connection time out

相关问题