crng init 卡住是因内核启动早期熵不足，需等待足够随机性；常见于虚拟机、容器等缺乏硬件RNG的环境，表现为启动慢、SSH延迟、/proc/sys/kernel/random/entropy_avail长期低于100。
为什么 crng init 卡住几分钟？
Linux 内核在启动早期需要足够熵（entropy）来初始化密码学随机数生成器（CRNG），否则会阻塞直到收集到足够随机性。现代虚拟机、容器或无硬件 RNG 的嵌入式设备常因缺乏熵源而卡在 random: crng init done 之前，表现为系统启动慢、SSH 登录延迟、openssl rand 等命令 hang 住。
常见现象包括：dmesg | grep -i random 显示长时间停留在 random: crng init not ready；cat /proc/sys/kernel/random/entropy_avail 长期低于 100（理想应 >200）。
haveged vs rng-tools：选哪个更靠谱？
二者都用于补充熵池，但机制和适用场景不同：
-
haveged基于 CPU 时间戳抖动提取熵，启动快、依赖少，适合大多数 x86_64 虚拟机和云实例 -
rng-tools依赖硬件 RNG（如 Intel RDRAND、AMD SVM），需确认 CPU 支持且内核已启用CONFIG_HW_RANDOM_INTEL或类似选项；否则可能静默失效
实际建议：
- 优先试
haveged：安装后默认即用，无需额外配置硬件 - 若已有可信硬件 RNG（如 AWS c5/c6、GCP e2，或物理服务器带 TPM/RDRAND），再启用
rng-tools并验证是否真正注入熵（rngd -f -v查日志） - 切勿同时运行两者，避免熵源冲突或重复注入导致内核熵计数异常
实操：快速启用 haveged 并验证效果
Ubuntu/Debian：
sudo apt install haveged sudo systemctl enable haveged sudo systemctl start haveged
CentOS/RHEL 8+：
sudo dnf install haveged sudo systemctl enable haveged sudo systemctl start haveged
验证是否生效：
- 检查服务状态：
systemctl status haveged应为 active (running) - 查看熵值变化：
watch -n1 'cat /proc/sys/kernel/random/entropy_avail'，几秒内应从 - 观察内核日志：
dmesg | grep -i "crng|random"，确认出现random: crng init done
注意：haveged 默认以非特权用户运行，若 SELinux 启用，可能需临时设为 permissive 模式排查权限问题；某些精简镜像（如 Alpine）需手动编译或换用 rng-tools。
/dev/random 仍阻塞？检查内核参数和容器环境
即使熵池充足，某些旧应用或容器仍可能因以下原因卡住：
- 内核启用了
random.trust_cpu=0（尤其在较新 kernel 中默认开启），抑制了 RDRAND 等硬件熵源 - 容器未挂载
/dev/random和/dev/urandom（Docker 默认已挂载，但 LXC/LXD 或自定义 runtime 可能遗漏） - systemd 服务设置了
RestrictAddressFamilies=AF_NETLINK等限制，间接影响熵获取路径
临时缓解可加启动参数（仅调试用）：
random.trust_cpu=1但更稳妥的做法是确保
haveged 运行 + 容器共享宿主机的 /dev/random（Docker 无需额外操作，Podman 需加 --device /dev/random:/dev/random）。
熵补充不是“越快越好”，而是要稳定、可信、不干扰内核 CRNG 初始化流程。最容易被忽略的是：很多云平台镜像已预装 haveged，但服务被 disable；还有人误以为装了就万事大吉，却没验证 entropy_avail 是否真实上升。
