故障排查
症状、成因、修复
| 症状 | 成因 | 修复 |
|---|---|---|
SSH 报 Connection refused | 你用了端口 22，或者实例还没到 running | 从连接标签页复制命令；等到 running 标记出现 |
你启动的服务报 Connection refused | 该端口在启动时从未被发布 | 通过 SSH 转发，或者在模板上声明它并重新部署 |
Permission denied (publickey) | 部署时没有附加密钥，或者你的客户端提供了另一把密钥 | 附加密钥后重新部署；或者用 -i 和 IdentitiesOnly=yes 指向正确的密钥 |
REMOTE HOST IDENTIFICATION HAS CHANGED | 一对被回收的主机和端口现在属于一个新实例 | ssh-keygen -R "[host]:port"，然后重新连接 |
实例一直停在 creating | 一个很大的镜像还在拉取 | 盯着日志标签页；如果它落到 error，就销毁并重新部署 |
实例处于 error | 工作负载启动失败、运行中失败或丢失，或者自己运行结束了。实例页面上的出了什么问题会说明是哪一种，API 的 error_code 也会——参见实例为何失败 | 读日志，销毁它，重新部署——它既不能启动也不能停止 |
JupyterLab 返回 403 Forbidden | 请求没有带令牌，或者带的是过期的令牌 | 回到控制台，重新用打开 JupyterLab |
模板的网页界面或 API 返回 401 | 这个端口要求实例访问令牌，而请求既没带令牌，也没带打开按钮设置的 cookie | 用打开按钮打开，或者在脚本里发送 Authorization: Bearer <访问令牌>。参见实例访问令牌 |
| 浏览器警告证书不受信任 | 通过直连地址打开时，JupyterLab 用自签名证书提供 HTTPS 服务 | 属于预期情况；忽略警告继续。参见证书警告 |
No space left on device | 你在部署时选的磁盘满了 | 清出空间，或者用更大的磁盘重新部署——磁盘无法调整容量 |
| 实例自己停了 | 组织的余额降到了 ¥0 | 充值余额，然后重新启动它 |
启动时返回 409 CAPACITY_UNAVAILABLE | 余额用完时实例的 GPU 被释放了（被自动停止的，或者你之前自己停止的），而原来那几块 GPU 现在正被别人使用，或者在那台机器上已停止服务 | 稍后再启动；实例保持停止，磁盘完好，但启动成功之前拿不到磁盘上的数据。一直不成功的话，销毁它（磁盘会一起删除）并重新部署 |
实例启动后又回到了 stopped | 主机拒绝了恢复、当前未连接、30 分钟内没有确认，或者原来的 GPU 正被别人使用或已停止服务；控制台会提示原因 | 稍后再启动。START_REFUSED 反复出现时，销毁实例并重新部署 |
停止后实例又回到了 running | 主机在 30 分钟内没有确认停止；容器其实还在运行，并在计费。实例页面会显示上一个操作没有完成，API 的 error_code 为 stop_timed_out | 什么都不用做——停止会自动重试。不需要这个实例的话，就销毁它 |
已停止的实例变成了 error，error_code 为 workload_gone | 实例停止期间，它的容器在机器上不见了 | 没有东西可以启动了：销毁它并重新部署。它不再计费 |
| 实例整个消失了 | 余额在 ¥0 或以下持续 24 小时并降到 −¥35，已停止的实例被销毁了 | 磁盘已经没了；充值余额并重新部署 |
API 返回 409 INVALID_STATE | 实例正处于状态转换中 | 等过渡状态完成后重试 |
部署或启动时返回 402 INSUFFICIENT_BALANCE | 组织的余额不够这个实例一小时的 GPU 加磁盘、再加上组织其他实例一小时的费用；余额为正也可能不够 | 由 admin 充值余额；member 不能 |
部署时返回 409 INSTANCE_LIMIT_REACHED | 组织里尚未销毁的实例已有 25 个，已停止和出错的也算在内 | 销毁不再需要的实例，包括处于 error 的 |
Connection refused
同一条消息背后是两个不同的问题。
如果是 SSH 本身，那你几乎肯定用错了端口。实例的 sshd 发布在启动时分配的某个主机端口上，绝不会是 22，而且这个号码在停止再启动之后可能改变。从连接标签页重新复制一遍命令。
如果是你在实例里启动的服务，那就是端口没有被发布。端口在实例启动时就固定了，所以之后再起服务器不会暴露任何东西。通过你已经建立的 SSH 会话把它转发出来：
ssh -N -L 8000:localhost:8000 -p 40123 root@203.0.113.14
同时确认进程绑定的是 0.0.0.0 而不是 127.0.0.1——除非这个端口在访问代理后面，那时应用就该在 127.0.0.1 上。参见端口与打开按钮。
Permission denied (publickey)
密码认证已被禁用，所以这总是意味着你的客户端提供的密钥不是 authorized_keys 里的那一把。
ssh -i ~/.ssh/id_ed25519 -o IdentitiesOnly=yes -p 40123 root@203.0.113.14
如果还是失败，最可能的情况是这个实例根本没有密钥——部署页面上的 SSH 密钥选择器留在了不使用密钥（仅网页终端）。没有办法给运行中的实例附加密钥。在 SSH 密钥中添加密钥，然后重新部署。参见添加密钥。
卡在 creating
creating 通常远不到一分钟就能完成。拉长它的是镜像拉取：一个几 GB 的镜像落到从未见过它的主机上，该花多久就花多久。日志标签页会显示拉取那一行，然后是 image ready, creating container。
如果工作负载始终起不来，实例会自己转到 error。它不会永远停在 creating。
处于 error 的实例
error 意味着工作负载没有在运行，平台也没有替你保留它。最常见的是容器启动失败，原因只存在于日志里，所以在清理之前先把日志读了：
- 镜像或标签不存在，或者私有镜像的仓库凭据不对。
- 模板固定使用的镜像与启动模式不匹配。
ssh和jupyter模式需要基于 Superheat 基础镜像构建的镜像。 - 工作负载在平台的启动时间窗口内始终没有就绪。
args 模式的命令自己退出了，实例也会进入 error，API 的 error_code 为 workload_completed：任务已经结束，GPU 已释放，也不再计费。
onstart 执行失败不在这些成因之列。基础镜像会在子 shell 里运行它，把失败写到 /var/log/superheat/onstart.log，并让容器继续运行，这样你可以连上去修。
处于 error 时唯一可用的操作是销毁。修好模板，然后重新部署。参见查看日志。
JupyterLab 返回 403
notebook 服务器只接受一种凭据，就是平台在部署时生成的令牌。返回 403 意味着浏览器发过去的令牌不对，或者根本没发，而这通常说明这个标签页是从书签或复制来的地址打开的，而不是从控制台打开的。
回到控制台里的那个实例，按打开 JupyterLab。这个按钮会带上平台为该实例生成的令牌；手工拼出来的地址不会。参见打开 JupyterLab。
磁盘空间用尽
df -h /
du -sh /workspace/* | sort -h | tail
常见的元凶是堆积的检查点和包缓存：
rm -rf ~/.cache/pip ~/.cache/huggingface
磁盘无法扩容。如果任务确实需要更多空间，把现有的数据从实例上拷贝出来，销毁它，再用更大的 disk_gb 重新部署。参见磁盘与存储。
实例自己停止了
当组织的余额降到 ¥0 时，运行中的实例会被自动停止。什么都不会丢——磁盘保留下来，一旦余额够它和组织里其他实例跑一小时，实例就能重新启动。但实例停着的这段时间存储费仍然从已经空了的余额里扣，所以余额会继续往下掉。
在机器支持的地方，这次停止还会把 GPU 释放回市场。之后启动要拿回原来那几块 GPU；它们正被别人使用或已停止服务时，启动会失败——要么返回 409 CAPACITY_UNAVAILABLE，要么实例回到 stopped、实例页面显示上一个操作没有完成——实例保持停止、磁盘完好，稍后再试即可。参见 GPU 被释放之后。
如果余额在 ¥0 或以下持续 24 小时并降到 −¥35，已停止的实例会被销毁，磁盘也一并消失。在计费页面查看余额和流水，并参见自动停止与自动销毁。
余额低于 ¥0 时，你的数据还在——至少 24 小时，而且直到余额降到 −¥35。两者都过去之后，已停止的实例会被销毁，无法恢复。