chronyd启动失败：权限不足无法同步系统时间

chronyd 启动失败并报错“Could not step system clock”，本质是普通用户进程因缺失 CAP_SYS_TIME 权限而被内核禁止直接跳变系统时间，尽管渐进式调时（slew）仍可正常工作，但大时间偏差下 chronyd 默认优先尝试高权限的 step 操作，失败即退出；真正有效的修复不是降权运行或禁用 step，而是通过 setcap 授予二进制文件能力，并关键性地在 systemd service 中同步配置 CapabilityBoundingSet 和 AmbientCapabilities——二者缺一不可，尤其在现代 RHEL/CentOS 等系统中，仅设 setcap 往往无效；掌握这一权限机制与配置协同逻辑，才能既保障时钟精准同步，又守住最小权限安全原则。

chronyd 启动时提示 “Could not step system clock” 是什么问题

这是 chronyd 在初始化阶段尝试用 clock_settime() 直接跳变系统时间（即“step”）失败导致的，不是警告，是硬性错误，会导致服务退出。根本原因通常是内核禁止非特权进程修改系统时钟，而 chronyd 默认以普通用户（如 _chrony）运行，没有 CAP_SYS_TIME 能力。

为什么 adjtime(2) 成功但 clock_settime(2) 失败

adjtime() 是渐进式调速（slew），仅调整时钟频率，不改变当前时间戳，普通用户可调；clock_settime(CLOCK_REALTIME, ...) 是直接写入新时间，属于高危操作，受 Linux capability 限制。chronyd 启动时若检测到系统时间偏差过大（默认 > 0.128 秒），会优先尝试 step（更快收敛），失败后才 fallback 到 slew —— 但若 step 失败且未配置允许降级，就直接报错退出。

• chronyd -d -x 可强制只用 slew 模式（绕过 step），适合调试
• 实际生产中不建议长期用 -x，它无法修正大偏差，可能让 NTP 同步失效
• 检查偏差大小：chronyc tracking 中的 System time offset

修复 “Could not step system clock” 的三种可行方式

核心是让 chronyd 进程获得 CAP_SYS_TIME，而非改用 root 运行（不安全）：

• 给 chronyd 二进制文件添加 capability：sudo setcap cap_sys_time+ep /usr/bin/chronyd
• 确认生效：getcap /usr/bin/chronyd 应输出 /usr/bin/chronyd = cap_sys_time+ep
• 若使用 systemd，需在 service 文件中显式声明能力（否则 setcap 可能被忽略）：
  CapabilityBoundingSet=CAP_SYS_TIME 和 AmbientCapabilities=CAP_SYS_TIME
• 重启服务：sudo systemctl restart chronyd，再查 journalctl -u chronyd -n 20

/etc/chrony.conf 中的 makestep 配置影响 step 行为

makestep 指令控制 chronyd 是否以及何时执行 step，它不解决权限问题，但决定是否触发该错误：

• makestep 1.0 -1：偏差 ≥1 秒时无条件 step（最可能触发错误）
• makestep 0.128 3：仅在启动后前 3 秒内、偏差 ≥128ms 时 step（更保守）
• makestep 0 0：完全禁用 step（等同于 -x，不推荐）
• 注意：即使配置了 makestep，若 capability 缺失，仍会报错退出，不会静默 fallback

今天关于《chronyd启动失败：权限不足无法同步系统时间》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！