Linux 線上替換運行中文件：避開 cp 陷阱，掌握 mv/rsync 原子性替換之道

在 Linux 生產環境中，替換正在被進程使用的文件（二進制可執行檔、共享庫 `.so`、配置檔、靜態資源）是高風險操作。錯誤使用 `cp`/`scp` 會導致進程崩潰、邏輯錯誤、甚至觸發 `SIGBUS` 信號。本文深度剖析底層機制，確立 **`mv`/`rsync` 原子性替換** 為唯一正規作法，並提供標準化操作流程與驗證清單。

核心機制：為什麼 `cp` 會導致災難？

`cp` 的破壞性行為

1. 截斷後寫入：`cp src dst` 實際執行 `open(dst, O_WRONLY|O_TRUNC)` → `write()` → `close()`。目標文件 **inode 不變**，但內容被瞬時清空並重寫。
2. 進程即時感知：已打開該文件的進程（通過文件描述符 FD）直接讀取新內容，**無需重新打開**。
3. 後果：
   • 可執行檔：文本段被修改 → 指令流錯亂 → **進程崩潰**（通常 `cp` 會報 `Text file busy` 拒絕覆蓋運行中二進制）。
   • 共享庫：`mmap` 映射區長度變短 → 訪問超出新文件大小的舊映射區 → **`SIGBUS` 核心傾印**。
   • 配置/資源文件：邏輯突變 → 業務錯誤、數據不一致。

`mv` 的原子性安全機制

1. 目錄項操作：`mv new dst` 僅修改目錄條目，**舊文件 inode 不變**，新文件佔用新 inode 取代目錄項指向。
2. 進程隔離：舊進程繼續持有舊 inode 的 FD，**完全不受影響**，讀取舊內容、舊映射區有效。
3. 新進程見新：後續打開文件的進程獲取新 inode，**平滑過渡**。
4. 跨文件系統：同分區 `mv` 為原子重命名；跨分區退化為 `cp` + `unlink`，**生產環境必須確保源目標同分區**。

`rsync` 的替代方案

rsync -a --inplace --no-whole-file new_file target_file
# --inplace: 直接寫入目標文件(非建立臨時文件再重命名)，但仍有截斷風險
# 更安全模式:
rsync -a new_file target_file.new && mv target_file.new target_file
# 利用 mv 原子性重命名完成切換

標準化操作流程（SOP）

場景 A：替換二進制可執行檔 / 共享庫

# 1. 驗證新文件完整性
sha256sum new_binary
file new_binary          # 確認架構、動態鏈接信息
ldd new_binary           # 依賴檢查

# 2. 確保同分區（關鍵！）
df -h /opt/app/bin/      # 目標目錄掛載點
df -h /tmp/new_binary    # 源文件掛載點
# 必須相同掛載點

# 3. 原子替換
mv /tmp/new_binary /opt/app/bin/app_binary

# 4. 重啟服務（必要步驟）
systemctl restart app-service
# 或滾動重啟：新流量導向新進程，舊進程優雅退出

場景 B：替換配置文件（無需重啟進程，支援熱加載）

# 應用支援 SIGHUP/信號熱加載
mv /tmp/new_config.yaml /etc/app/config.yaml
kill -HUP $(pidof app)   # 觸發重讀配置

# 應用不支援熱加載 -> 必須重啟
mv /tmp/new_config.yaml /etc/app/config.yaml
systemctl restart app

場景 C：大量文件/目錄同步更新（靜態資源、代碼部署）

# 1. 準備新版本目錄 (同分區)
rsync -a --delete /source/new_version/ /deploy/staging/

# 2. 原子切換符號鏈接 (推薦：藍綠部署/當前版本指針)
ln -sfn /deploy/staging /deploy/current
# -f 強制覆蓋 -n 不解引用目標目錄 -s 符號鏈接
# 此操作原子性更新 /deploy/current 指向

# 3. 通知服務重載 (如 Nginx)
nginx -s reload

避坑指南：常見錯誤與修正

驗證清單（替換後必執行）

1. inode 變更確認：`ls -li /path/to/file` 對比替換前後 inode 號是否改變（`mv` 應改變，`cp` 不變）。
2. 進程映射檢查：`lsof -p | grep ` 或 `cat /proc//maps | grep ` 確認進程持有的是新 inode（重啟後）。
3. 功能冒煙測試：關鍵 API/功能路徑自動化驗證。
4. 日誌無錯誤：`journalctl -u service -f` / `tail -f /var/log/app.log` 觀察啟動/重載過程。

容器化環境特殊考量

• 映像不可變：容器內文件替換違背不可變基礎設施原則。**正確路徑：構建新映像 → 推送倉庫 → 滾動更新 Pod**。
• 掛載卷熱更新：ConfigMap/Secret 更新 → Volume 掛載自動傳播（SubPath 除外）→ 應用需支援熱加載或 Sidecar 監聽觸發重啟。
• 共享庫注入：`LD_PRELOAD`/掛載 `lib` 目錄替換庫文件，屬高風險 Hack，僅限臨時診斷，禁用於生產常態。

Linux 線上文件替換的鐵律：**拒絕 `cp`/`scp` 直接覆蓋運行中文件，擁抱 `mv` 原子重命名（同分區）與 `rsync`+`mv` 兩階段模式，配合服務優雅重啟/熱加載機制**。將此 SOP 內嵌至 CI/CD 部署腳本、Ansible Playbook、Runbook 手冊，以機制對抗人為失誤，守護生產穩定。