亚马逊云免绑卡账号 AWS亚马逊云服务器重启问题

你有没有经历过这种窒息时刻——点下「Reboot Instance」按钮，眼睛盯着控制台，心跳跟着状态栏跳：running → stopping → pending → ……然后卡住不动了。十分钟过去，它还是pending；半小时后，你开始怀疑自己是不是误点了「宇宙重启协议」？

别慌。这不是玄学，也不是AWS偷偷给你开了个玩笑——这是EC2在用它的方式，对你喊话：“兄弟，我身体有点堵，但没说清楚哪儿堵。”

今天不画大饼、不甩文档链接、不背AWS白皮书。咱们就坐下来，泡杯茶（或续命咖啡），像两个运维老友一样，把EC2重启失败这事，一桩桩、一件件，掰开揉碎了聊透。

亚马逊云免绑卡账号 先划重点：重启 ≠ 重装，更不是「假装重启」

很多人第一反应是：“重启不行？那我终止再启动呗！”——停！这相当于把车熄火后直接拖去4S店换发动机。EC2的Reboot是操作系统级软重启：内核不重载、网络接口不重置、EBS卷不卸载、IP地址不漂移。它该秒回，不该卡顿。一旦卡在pending，说明底层出了“轻伤不下火线”的问题。

七种常见堵点，照着顺序查，90%能当场破案

① 系统盘EBS卷被挂载为只读（Read-only filesystem）

最冤的锅。系统启动时检测到磁盘错误（比如突然断电、IO超时），Linux会自动将根分区remount为ro。此时哪怕你发起reboot，init进程也卡在“无法写入/var/run/reboot.lock”这类路径上——它想关机，但连关机日志都写不进去。

怎么确认？进EC2控制台→选实例→「Actions」→「Monitor and troubleshoot」→「Get system log」。如果日志最后几行反复出现：EXT4-fs error (device nvme0n1p1): ext4_remount:5169: aborting journal on readonly filesystem，恭喜，你中奖了。

解法：必须Stop→Start（注意：不是Reboot）。Stop会强制卸载EBS，Start时触发fsck自动修复。修复完再reboot，世界清静。

② ENI（弹性网卡）绑定异常

尤其多网卡、多安全组、启用了“描述性ENI名称”的环境。某次安全加固后，有人把主ENI的“删除时终止”选项手动关了，结果重启时AWS尝试解绑ENI失败——因为ENI正被其他服务（比如Lambda VPC连接）悄悄占用。控制台显示pending，其实是网络层在死锁。

快检命令：在能SSH登录时跑：aws ec2 describe-network-interfaces --filters "Name=attachment.instance-id,Values=i-xxx"。看Attachment.Status是否卡在attaching。

急救包：删掉非必需ENI，或临时禁用Secondary ENI的自动分配IP功能。

③ 自定义AMI里的systemd服务自启死循环

你自己打包的AMI，加了个监控脚本，设成WantedBy=multi-user.target，但它启动时依赖一个还没起来的Docker socket……于是systemd反复拉起又kill，死锁在启动图谱里。reboot命令发下去，systemd根本没机会执行shutdown.target。

证据在哪？「Get serial console output」（需提前开启serial console权限）。里面能看到systemd启动树卡在某个service的start-pre阶段，且timeout计数不断+1。

根治法：Stop实例→分离根卷→挂到另一台健康EC2当数据盘→修改/etc/systemd/system/xxx.service，加TimeoutStartSec=30或注释掉Problematic ExecStart。

④ 实例存储型（Instance Store）实例的“假重启”陷阱

t2/t3这类突发性能实例，根设备若用的是instance store（而非EBS），重启时整个本地盘内容全丢。但AWS控制台仍显示“rebooting”，因为它真在重启——只是重启完发现/boot分区没了，卡在grub rescue模式。你等它，它在等不存在的kernel。

避坑口诀：永远不用instance store做系统盘，除非你写的代码自带“开机自重建文件系统”功能。

⑤ 安全组/网络ACL悄悄封杀了169.254.169.254

别笑！真有团队在搞零信任改造时，把元数据服务IP段全deny了。而EC2重启流程中，需要调用http://169.254.169.254/latest/meta-data/获取新实例ID、区域信息等。访问超时→状态机阻塞→pending无限循环。

验证法：SSH进实例后：curl -I -m 2 http://169.254.169.254/latest/meta-data/。返回403或timeout？立刻检查NACL出方向规则第100条是否放行UDP/ICMP+TCP 80到169.254.0.0/16。

⑥ Nitro平台上的UEFI固件bug（仅影响较老Nitro AMI）

2022年前某些Amazon Linux 2 Nitro AMI存在UEFI启动栈缺陷：重启时固件未正确释放PCIe设备资源，导致NVMe控制器hang住。现象极典型——串口日志停在ACPI: EC: EC started之后，再无任何输出。

速判：用最新版AL2023或Ubuntu 22.04 AMI新建实例对比测试。若新AMI正常，旧AMI必升级。

⑦ “你以为在重启，其实AWS在热迁移”

底层宿主机硬件告警（如内存ECC错误率超标），AWS会触发自动热迁移。此时控制台显示“rebooting”，实则是实例被无声迁移到新物理机，旧实例已终止。你看到的pending，是旧实例状态残留——等3分钟，它会自动变成terminated，新实例已在别处running。

查证姿势：进「CloudTrail」搜RebootInstances事件，看是否有后续的TerminateInstances和RunInstances关联事件。有？那就是AWS替你做了人生选择题。

终极诊断包：三行命令，5秒定性

把下面脚本存成ec2-reboot-diag.sh，遇到pending立刻跑：

#!/bin/bash
echo "【1】检查系统日志末尾："; sudo tail -20 /var/log/messages 2>/dev/null | grep -i -E "error|fail|readonly|panic"
echo -e "\n【2】检查systemd启动状态："; systemctl list-units --state=failed --no-pager 2>/dev/null
echo -e "\n【3】检查元数据服务可达性："; timeout 3 curl -s -o /dev/null -w "%{http_code}" http://169.254.169.254/latest/meta-data/ 2>/dev/null || echo "TIMEOUT"

写在最后：重启不是银弹，而是镜子

每次重启失败，都是系统健康度的一次快照。它照出你AMI是否做过充分验证，照出网络策略是否留了逃生通道，照出监控是否覆盖了“启动完成”这个关键状态点。

所以，下次再看到那个倔强的pending，别急着点Stop。先深呼吸，打开串口日志，念一句：“来，咱俩好好聊聊，你到底卡在哪儿了？”——毕竟，云不会撒谎，它只是说话的方式，需要你听得更认真一点。