当前位置：首页 > 文章列表 > 文章 > linux > Linux getrandom 读取为何会阻塞：熵池就绪、系统调用返回与启动阶段排查

Linux getrandom 读取为何会阻塞：熵池就绪、系统调用返回与启动阶段排查

来源：17golang原创 2026-08-30 06:23:06 0浏览收藏

有些 Linux 服务启动时没有明显的 CPU 或磁盘告警，却长时间停在“生成随机值”这一步。程序通过 getrandom 从内核随机源取数据时，如果熵池尚未初始化，默认行为就是等待；这不等于服务死锁。

排查重点是先确认熵池是否已经就绪，再区分默认阻塞、GRND_NONBLOCK 返回 EAGAIN，以及大块读取带来的短读或 EINTR。

要点速览

默认的 getrandom 读取在熵池未初始化时会阻塞。
加上 GRND_NONBLOCK 后，不等待而是立即返回 EAGAIN。
初始化后的 urandom 源适合小块读取，单次不超过 256 字节更容易得到完整结果。
启动期应同时核对 systemd-random-seed.service、内核日志和 entropy_avail。

先判断：卡住的是随机源，还是应用自己的重试

Linux 3.17 引入的 getrandom(2) 不需要打开 /dev/random 或 /dev/urandom 文件。默认不设置标志位时，它从 urandom 源取数据；如果内核还没有完成随机源初始化，调用会睡眠等待。

现场可以先看进程状态和内核提示：

ps -o pid,stat,wchan:32,cmd -p 
dmesg -T | tail -80
cat /proc/sys/kernel/random/entropy_avail

这个数值只能作为线索，不能把 entropy_avail 当成“getrandom 一定马上返回”的倒计时。真正有区分度的是进程是否长期处于等待状态，以及服务日志是否与启动早期重合。

默认阻塞和 EAGAIN：只差一个标志位

下面这段最小示例故意只申请 32 字节，方便把返回值和错误分开观察。默认调用会等待熵池初始化；加上 GRND_NONBLOCK 后，如果此刻不能立即提供数据，返回值为 -1，并把 errno 设为 EAGAIN。

#include 
#include 

unsigned char buf[32];
long n = getrandom(buf, sizeof buf, GRND_NONBLOCK);
if (n

getrandom 默认阻塞与 GRND_NONBLOCK 返回 EAGAIN 的决策路径

图中只保留这个问题真正需要的分支：同一入口 getrandom，在非阻塞标志下走到 EAGAIN。如果程序把所有负数返回都当成致命错误，启动阶段就可能表现为随机失败；如果无条件循环重试，又可能把暂时不可用变成长时间自旋，代码需要明确自己的恢复策略。

读取长度会改变验收方式

随机源已经初始化后，读取不超过 256 字节的 urandom 数据有更强的完整返回保证；更大的请求则要按“可能短读”处理。尤其在信号处理程序介入时，返回值可能小于请求长度，或者得到 EINTR。

生成密钥材料、令牌或会话随机值时，优先拆成小块并检查每次返回：

size_t off = 0;
while (off  0) {
        off += (size_t)n;
        continue;
    }
    if (n

这段循环解决的是“已就绪后的传输完整性”，解决不了“熵池尚未初始化”的启动等待。两种情况要在日志里分开记，否则最后只会看到一个模糊的随机数错误。

启动阶段怎么把证据串起来

如果问题只出现在开机后的很短窗口，检查随机种子恢复服务是否被跳过、失败或晚于业务服务启动：

systemctl status systemd-random-seed.service
journalctl -b -u systemd-random-seed.service --no-pager
cat /proc/sys/kernel/random/entropy_avail

systemd-random-seed.service 的职责是启动时把保存的随机种子加载回内核随机池，并在关机时保存新的种子。它能帮助缩短启动期的等待，但不能替应用层隐藏返回值检查，也不能替代硬件或内核随机源的健康核对。

systemd-random-seed.service、entropy_avail 与 getrandom 启动排查因果链

一个可复现的判断顺序是：先看服务启动时间，再看随机种子单元日志，接着记录 entropy_avail，最后确认应用是否真的调用了 getrandom。如果前三项正常而应用仍反复收到 EAGAIN，问题更可能是容器、沙箱或应用自己的非阻塞重试策略。

几个容易误判的边界

不要用“/dev/urandom 通常不阻塞”推断早期启动一定不会等待；getrandom 的默认调用会等熵池完成初始化。
不要把 GRND_RANDOM 当成普通随机值接口；它走的是另一种随机源，返回和阻塞边界也不同。
不要只检查“返回值不是负数”；读取长度、EINTR 和短读都需要纳入验收。
不要仅凭 entropy_avail 一个数字判断故障已修复，要和服务日志及应用状态对照。

把排查结果落到一张清单

最终记录至少包括：调用是否带 GRND_NONBLOCK、每次请求的字节数、实际返回值与 errno、服务启动时间、systemd-random-seed.service 状态，以及同一时间点的内核日志。这样下次再遇到“启动卡住”，可以快速判断是随机源尚未就绪，还是应用把可恢复状态处理错了。