WebIDE 容器中 AtomCode 报 ATOMCODE_SIG_STALE 排查实录：一次由 8 小时时钟偏差引发的“悬案”

一、问题背景

在 Ubuntu HidevLab WebIDE 环境中使用 AtomCode 时，遇到了一连串看似不相关的报错：

❯ /model
    Switched to AtomGit-qwen38 · qwen3.8-27b; set as default for new sessions
❯ 继续
  [Error: HTTP 403: [ATOMCODE_SIG_STALE] 请求超时，请稍后重试。]

同时容器里还有一些“命令不支持”的现象，比如 timedatectl 直接报错：

System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down

另外 /usr/local/Ascend/ascend-toolkit/set_env.sh: No such file or directory 说明该容器是纯净的 Ubuntu 环境，未预装 CANN 工具包（如需昇腾 NPU 开发需另行安装或更换镜像）。
本文完整记录从现象到根因的排查过程，供遇到同类问题的同学参考。

二、环境摸底

先跑一组基础命令确认环境边界：

whoami && id            # root，uid=0(root) gid=0(root)
cat /etc/os-release     # Ubuntu 22.04.5 LTS (Jammy)
which sudo apt curl     # /usr/bin/sudo /usr/bin/apt /usr/bin/curl

结论：root 权限、Ubuntu 22.04、基础工具齐全，典型的 WebIDE/Docker 容器环境。

三、为什么有些命令“不支持”

WebIDE 容器和标准虚拟机有本质区别，很多命令不是坏了，而是容器架构下天然不可用：

四、定位真正的病根：时钟偏差

ATOMCODE_SIG_STALE 直译是“签名过期”。签名一般携带时间戳，如果客户端时间与服务器相差超过允许窗口（通常几分钟），服务端就会判定签名失效。

4.1 验证方法：对比本机时间与权威服务器时间

date -u; curl -sI https://www.baidu.com | grep -i ^date

实测输出：

Sun Aug 30 04:22:50 PM UTC 2026          ← 本机
Date: Sun, 30 Aug 2026 08:22:56 GMT      ← 真实权威时间

4.2 一个容易看错的地方：本机是“快”还是“慢”？

注意本机输出的 04:22:50 **PM** 是 12 小时制，即下午 4 点 = 24 小时制的 16:22:50；而服务器返回的 08:22:56 是 24 小时制。两者同为 UTC/GMT 时区，直接比数字：

• 本机：16:22:50
• 真实：08:22:56
• 差值：本机超前整整 8 小时
  机器“跑到了未来”，AtomCode 的请求带着“来自 8 小时后”的时间戳，服务端签名校验自然失败，返回 403 SIG_STALE。

4.3 偏差成因推断

超前整 8 小时是非常经典的宿主机时钟配置错误模式：宿主机硬件时钟（RTC）里存的是北京时间（UTC+8），但系统启动时把 RTC 当作 UTC 读取，于是系统时间 = 北京时间 + 8 = 比真实 UTC 快 8 小时。
容器与宿主机共享同一个内核时钟，所以根子在宿主机，容器内无解。

五、确认容器内无法改时钟

capsh --print | grep -E 'cap_sys_time|Current'

输出中 !cap_sys_time（感叹号表示被剥离），且无 cap_sys_admin：

Current: cap_chown,cap_dac_override,...,cap_setfcap=ep
Current IAB: !cap_sys_admin,...,!cap_sys_time,...

结论：即使以 root 身份，date -s 也会被内核直接拒绝，容器内修改系统时钟这条路物理封死。

六、解决方案

6.1 临时自救：libfaketime（只对单个进程伪造时间） 好像没有效果

libfaketime 通过 LD_PRELOAD 拦截进程的时间系统调用，让指定进程“以为”现在是正确时间，不影响系统其他部分：

apt update && apt install -y faketime
# 第一步：验证回拨 8 小时是否生效，应显示 08:2x UTC
faketime -f '-8h' date -u
# 第二步：确认 atomcode 是动态链接（faketime 的前提）
ldd $(which atomcode)

• 如果 ldd 列出 .so 依赖 → 可以用 faketime -f '-8h' atomcode <命令> 运行
• 如果输出 not a dynamic executable（静态编译二进制）→ faketime 拦不到，此路不通

好像没有效果

6.2 治本：报修平台，修宿主机时钟

把证据链原样发给 WebIDE 平台方，定位很快：

容器内 date -u 显示 Sun Aug 30 16:22:50 UTC，curl -sI https://www.baidu.com 返回 Date: Sun, 30 Aug 2026 08:22:56 GMT，容器时钟超前 8 小时。疑似宿主机 RTC 以本地时间存储但被系统当作 UTC 读取。请在宿主机执行：

timedatectl set-local-rtc 0
timedatectl set-ntp true

修复后确认 timedatectl status 中 RTC in local TZ: no。

6.3 ⚠️ 重要：时钟修复后，AtomCode 需要重启才能生效 好像没有效果

无论是平台侧修好了宿主机时钟，还是你用 faketime 方式绕过，都请注意一点：
AtomCode 进程在启动时读取并缓存了系统时间，时钟修正后正在运行的旧进程仍持有错误的时间基准，签名会继续失败。必须重启 AtomCode 进程/会话，让它重新加载正确时间，之后签名校验才能恢复正常。
实操建议：

# 杀掉旧进程后重新启动
pkill -f atomcode        # 或按平台方式停止服务
atomcode <你的命令>       # 重新启动
# WebIDE 场景下，稳妥的做法是：先修时钟 → 退出当前终端会话 → 重新打开

同理，如果你的 WebIDE 环境因时钟偏差出现过证书校验失败、token 提前过期等问题，修复时钟后相关服务也建议一并重启。

七、延伸影响

时钟快 8 小时不只影响 AtomCode 一个工具，以下都会连带出错：

• HTTPS 证书校验：证书"尚未生效”或“已过期”误判
• 各类 token/JWT 有效期判断：明明刚登录就被判定过期
• 日志时间戳：排查问题时时间线错乱 8 小时
• 签名类 API 调用：凡带时间戳签名的服务都会拒绝请求
  因此这个宿主机时钟问题值得平台优先修复——而且这台宿主机上所有用户的容器都会中招，不只是你一个。

八、排查思路总结

回头看，整个排查路径其实是一条标准的"由现象到根因"链条：

1. 看到 403 SIG_STALE → 怀疑签名/时间问题
2. 对比本机与权威时间（date -u vs curl 返回的 Date: 头）→ 发现超前 8 小时
3. 注意 12/24 小时制陷阱（PM = +12）→ 确认方向是“快”不是“慢”
4. 检查内核能力（capsh --print）→ 确认容器内改不了时钟
5. 临时方案 faketime + 治本报修宿主机 → 双线并行
6. 修完后重启 AtomCode → 让进程重新加载正确时钟
   一句话总结：遇到签名过期类报错，先看时钟准不准；容器里时钟不对，根因大概率在宿主机；修完时钟，记得重启相关进程。