遠端 Mac SSH 斷線後打包會停嗎？2026 持續任務方案

Apple 的 xcodebuild 命令列參考把退出狀態列為判斷建置結果的重要訊號；因此，遠端 Mac SSH 斷線打包時，不能只看終端機畫面有沒有繼續刷新。本週先把長任務移到可重連會話、分開保存日誌與產物，再用主動斷線及主機重啟測試驗收；重複發布則交給 CI Runner 或受管理的背景作業。

這篇適合沒有本地 Mac、透過 SSH 執行 iOS Archive 或測試的 Windows/Linux 開發者，也適合需要夜間建置、定時測試或 TestFlight 發布的小團隊。若目前環境在網路中斷後無法判斷任務究竟是繼續、失敗，還是只剩下不完整畫面記錄，以下流程可用來重新建立證據鏈。

SSH 斷開後，xcodebuild 可能出現的結果不能被簡化成「一定停止」或「一定繼續」。真正需要區分的是：

• 工作階段跟著終端機結束：前台 Shell 失去連線，子程序也被終止，最後沒有完整退出狀態。
• 建置仍在執行，但畫面記錄消失：程序可能仍存在，可是重連後看不到完整標準輸出與錯誤輸出。
• 程序還在，建置卻已阻塞：例如等待使用者登入、Keychain 授權、Simulator 或其他圖形會話，表面上仍有程序，產物卻沒有更新。

Apple 對 Remote Login 的設定與 SSH 登入格式有明確說明，但 SSH 連線、Shell 會話、建置程序及使用者登入會話不是同一層。可先依照 Apple 的 Remote Login 說明確認登入本身正常，再驗證任務是否真的完成。

因此，終端機視窗是否刷新只能算觀察線索，不能當成驗收結果。至少要同時核對程序狀態、完整日誌、退出狀態，以及 xcresult、xcarchive 或導出檔案是否存在。

單次 Build、Test 或 Archive 可以使用可重連的終端會話，但重點不是記住某個工具名稱，而是讓工作脫離單一 SSH 前台 Shell，並為每次任務建立獨立證據。以下範例中的帳號、路徑、專案和 Scheme 都是佔位符：

mkdir -p "$HOME/build-records/<JOB_ID>" "$HOME/build-output/<JOB_ID>"

xcodebuild \
  -workspace "<PROJECT>.xcworkspace" \
  -scheme "<SCHEME>" \
  -configuration "Release" \
  -destination "generic/platform=iOS" \
  archive \
  -archivePath "$HOME/build-output/<JOB_ID>/<APP>.xcarchive" \
  > "$HOME/build-records/<JOB_ID>/stdout.log" \
  2> "$HOME/build-records/<JOB_ID>/stderr.log"

status=$?
printf '%s\n' "$status" > "$HOME/build-records/<JOB_ID>/exit-status"
printf '%s\n' "$(date)" > "$HOME/build-records/<JOB_ID>/finished-at"
exit "$status"

這個流程有幾個不可省略的邊界：

• 標準輸出與錯誤輸出分開保存，重連後不必依賴殘缺的螢幕歷史。
• 退出狀態另存為檔案，避免 Shell 退出後只剩「看起來跑完」的印象；Apple 的 Xcode 環境變數與建置結果文件可作為判讀命令列建置結果的官方依據。
• archivePath 使用獨立目錄，讓本次 xcarchive 不會被下一次任務覆蓋。
• 任何會終止程序的操作，都應先記錄工作階段、程序識別碼與預期影響；若確認是錯誤任務，再按既定回退方式停止，而不是直接刪除整個輸出目錄。

斷線後的重連檢查

重新登入遠端 Mac 後，不要立即重新執行整條命令。先檢查：

cat "$HOME/build-records/<JOB_ID>/exit-status"
tail -n 80 "$HOME/build-records/<JOB_ID>/stdout.log"
tail -n 80 "$HOME/build-records/<JOB_ID>/stderr.log"
find "$HOME/build-output/<JOB_ID>" -maxdepth 2 -type d -name "*.xcarchive"

若退出狀態尚未出現，代表任務可能仍在執行，也可能在 Shell 層已失去控制；此時再查看程序、最近修改時間與輸出目錄。不要因為程序名稱仍存在，就直接判定建置成功。

長時間發布不應被寫成一條無法分段的命令。Archive、exportArchive、二進位檔上傳，以及 App Store Connect 後台處理，分別屬於不同階段；Apple 的 Archive 與導出流程與 Beta 測試及發布流程也將建置產物和發布流程分開處理。

建議為每一階段保留以下資料：

• Archive 階段：xcarchive 路徑、建置日誌、退出狀態。
• 導出階段：導出目錄、使用的設定檔、錯誤日誌及退出狀態。
• 上傳階段：上傳命令日誌、版本與建置編號、交付結果。
• 後台處理階段：App Store Connect 中可核對的處理狀態，而不是只依賴 SSH 命令已返回。

上傳命令恢復，不代表平台後台處理已完成。若網路在上傳途中中斷，先核對遠端平台是否已收到相同版本與建置編號，再決定重試；若尚未建立交付記錄，才考慮重跑上傳。至於 Archive 已成功但導出失敗，通常應從既有 xcarchive 重新導出，而不是重新編譯整個專案。

偶爾執行一次的手動 Archive，適合使用可重連會話；但頻繁提交、夜間測試及定時發布，不應長期依賴人工 SSH。此時要比較的是任務觸發方式、主機重啟後能否回來、使用哪個帳號執行，以及日誌是否可查，而不是工具功能清單。

• 可重連終端：適合臨時任務與人工觀察；主機重啟後通常需要重新建立會話並重新安排任務。
• CI Runner：適合由提交或排程觸發的重複建置；必須確認 Runner 啟動上下文、簽名資產可見性、工作目錄清理方式及失敗通知。
• launchd 背景作業：適合在明確使用者或系統上下文下啟動固定服務；Apple 的 launchd 作業說明指出，作業設定和執行上下文會影響它如何啟動與管理。

launchd 不是把互動式 SSH 命令換個地方貼上就完成。若作業依賴使用者登入、Keychain 或圖形授權，必須先確認它是在正確的使用者上下文執行。Apple 對 程序與登入會話的系統上下文已有說明；所以「主機已開機」不等於「簽名環境已可用」。

若要判斷 iOS 夜間打包應選可重連終端還是 CI Runner，可以使用這個條件：只有人工偶發操作，選可重連會話；需要排程、失敗通知及重試，選 CI Runner；需要主機啟動後自動拉起固定服務，才評估 launchd，並先完成登入上下文和 Keychain 驗收。

純命令列 Archive 和模擬器測試不是同一種任務。Xcode 測試結果應保存 xcresult，並依照 Apple 的測試與結果解讀文件核對失敗原因；如果測試涉及 Simulator，還要確認目前使用者會話與裝置狀態。

可用兩組對照任務縮小問題範圍：

• 先執行不依賴圖形介面的純命令列建置，確認 SSH、Shell、工具鏈與磁碟輸出正常。
• 再執行模擬器測試或需要簽名的任務，分別檢查 xcresult、Keychain 可見性、解鎖狀態與圖形登入會話。

若第一組成功、第二組失敗，問題未必是網路中斷；可能是使用者退出、Keychain 未解鎖、Simulator 不在預期會話，或背景作業使用了不同帳號。不要把放寬 Keychain 權限、調整背景權限或修改系統設定當成預設修復。任何權限變更都要先記錄影響範圍、原始設定與回退命令，並在驗收後恢復不必要的放寬項目。

在正式讓遠端 Mac 承擔夜間建置前，建議完成以下可勾選清單。每項都要留下日誌或檔案證據，不能只以人工觀察作結論。

• [ ] 建置進行中主動斷開 SSH，重新登入後確認程序、標準輸出、錯誤輸出、退出狀態及 xcarchive。
• [ ] 執行測試任務並保存 xcresult，確認網路中斷後能分辨測試失敗與日誌遺失。
• [ ] 在任務執行時退出使用者會話，分別驗證純命令列建置、Simulator、Keychain 簽名及需要圖形授權的步驟。
• [ ] 重啟主機後確認 SSH 服務、CI Runner 或 launchd 作業是否按預期回復，並檢查是否產生新的啟動日誌。
• [ ] 核對版本與建置編號，確認 Archive、導出檔及上傳交付記錄沒有被重複任務覆蓋。
• [ ] 模擬一次失敗，確認通知、退出狀態、日誌位置及重新執行範圍都已定義。
• [ ] 為每個權限修改保留回退方式，驗收完成後移除不再需要的放寬設定。

如果只是第一項通過，代表臨時連線方案尚可使用；若夜間、排程或重啟驗收失敗，應升級為常駐 Runner 或受管理的背景作業。若主機本身無法持續在線，日誌會因重啟遺失，或每次恢復都要依賴個人電腦重新登入，就不宜再把它當作可靠的 iOS 打包伺服器。

完成環境驗收後，可先閱讀 JEXCLOUD 的遠端 Mac 服務入口，再按任務頻率評估是否需要長期在線的 Mac。若現有電腦必須保持開機、容易因個人網路中斷而失去 SSH 會話，或沒有穩定的日誌與重啟恢復機制，繼續依賴它的隱性成本通常高於表面硬體支出；此時租用具備 root 權限的遠端 Mac，會比臨時拼接前台 SSH、個人電腦與手動重跑更容易完成取證和恢復。需要測試環境或持續打包時，再依照預計任務週期查看 JEXCLOUD 的遠端 Mac 方案，並先用上述斷線與重啟清單驗收，而不是直接把整條發布流程交給未測試的主機。