Linux chrt 的 reset-on-fork 怎样影响子进程调度

Linux chrt 的 --reset-on-fork（短选项 -R）不是把父进程恢复成普通调度，而是给当前线程设置一个“创建子进程时降级”的边界。父进程仍可保持 SCHED_FIFO 或 SCHED_RR；它随后通过 fork() 创建的子进程会改为 SCHED_OTHER，负 nice 值也会重置为 0，而且子进程中的 reset-on-fork 标志会被清掉。

先把 reset-on-fork 的作用范围划清

Linux 把调度策略和 reset-on-fork 标志作为线程属性处理。chrt -R 设置成功后，后续 fork(2) 产生的孩子不会继承父线程的特权调度策略。对于 SCHED_FIFO 或 SCHED_RR，孩子变成 SCHED_OTHER；如果父线程使用了负 nice 值，孩子的 nice 会回到 0。

这里有三个容易混淆的结论：第一，父进程不会因为 fork 自动降级；第二，之前已经创建的子进程不会被回溯修改；第三，标志在孩子中被清除，所以孙进程不会因为“祖父曾经设置过 -R”而继续套用这条规则。

用 chrt -R 启动可观察的父进程

测试时先让父进程自己保持实时策略，再让它执行会调用 fork() 的程序。下面命令使用 FIFO 优先级 50；真实环境中请先确认进程不会占满 CPU，并按发行版要求授予 CAP_SYS_NICE 或使用受控的管理员权限。

# 让父进程使用 FIFO 50，并在 fork 子进程时重置调度策略
chrt -f -R 50 -- ./parent-worker

# 读取一个已有 PID 的调度策略、优先级和 reset-on-fork 状态
pid=12345
chrt -p -v "$pid"

-f 选择 SCHED_FIFO，50 是实时优先级，-R 开启 reset-on-fork。若只想使用时间片轮转，把 -f 换成 -r；核心判断并没有变化。chrt -p -v 读取的是目标线程的当前状态，不能只拿父 PID 的结果推断所有线程。

按 PID 对照父子结果，而不是只看一条命令

让测试程序把 fork() 返回的子 PID 写入日志，然后分别检查两个 PID。父进程预期仍是 SCHED_FIFO 和原优先级，子进程预期是 SCHED_OTHER，其静态实时优先级为 0。不同版本的 chrt 输出格式可能略有差异，重点是策略、优先级和是否显示 reset-on-fork。

如果结果和表格不一致，先确认程序真的走了 fork()，而不是只调用 execve() 替换当前进程映像；再确认查看的是线程 ID 还是进程 ID。chrt 的 --all-tasks 可以遍历一个 PID 的线程，但它不能把线程级差异自动合并成一个结论。

权限和特殊策略的边界要提前处理

设置实时策略通常需要足够的权限；没有权限时，命令可能返回 Operation not permitted，这不是 reset-on-fork 逻辑失效。reset-on-fork 一旦启用，之后要清除它也需要 CAP_SYS_NICE。因此排查顺序应是：先读当前策略，再确认能力和资源限制，最后才判断父子策略变化。

SCHED_DEADLINE 还有更严格的边界：实时 deadline 线程调用 fork() 时，如果没有 reset-on-fork，系统调用可能以 EAGAIN 失败；设置标志只能解决这个继承限制，不能代替 deadline 的运行时间、截止时间和周期配置。生产环境还要考虑 cgroup CPU 控制、RLIMIT_RTTIME 与失控实时循环，不能把 -R 当成完整的资源隔离方案。

一份可复用的排查清单

1. 记录父 PID、子 PID 和创建方式，确认是 fork() 产生的子进程。
2. 分别执行 chrt -p -v PID，不要只读取父 PID。
3. 对照策略、静态优先级、nice 值和 reset-on-fork 标志四项结果。
4. 若出现权限错误，检查 CAP_SYS_NICE、实时资源限制与容器能力。
5. 测试完成后恢复普通策略，避免实验进程长期占用实时调度。

常见问题

父进程设置了 -R，为什么自己还是 SCHED_FIFO？

这是正常行为。标志只规定之后创建的 fork 子进程如何处理，不会修改设置它的父线程。

子进程 exec 之后还会保持 SCHED_OTHER 吗？

会。exec 替换的是进程映像，不会把已经由 fork 触发的调度策略恢复成父进程的 FIFO/RR。

为什么查看到的状态和预期不一样？

优先排查查看对象是否为正确的线程、程序是否真的 fork，以及当前用户是否有读取或设置调度属性的权限。

把 -R 理解成“实时父线程创建普通子进程的单向边界”，再结合父子 PID 对照，就能解释大多数看似反常的 chrt 结果。