疑難排解
症狀、成因、修法
| 症狀 | 成因 | 修法 |
|---|---|---|
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。兩者都過了之後，已停止的執行個體會被銷毀，而且無法復原。