テクノロジー · 実用ガイド
rsync の「file has vanished」—終了コード24を無視する前に送信元の変化を証明する
消えたパスをすべて保存し、作成・削除したプロセスを特定して、同じ送信元または安定したスナップショットで再実行します。
終了コード24は、送信元ファイルが途中で消えたため転送が一部だけ完了したことを示します。ライブツリーでは正常な場合もありますが、番号だけで欠落が無害とは判断できません。
安全な順序は証拠が先、ポリシーが後です。stderrと状態を保存し、パスを分類し、同じ送信元か時点固定の送信元で再実行してから修復・除外・限定的な格下げを選びます。
フィルター前に実行を保存する
stderrを日時付きログへ書き、直後にシェル状態を保存します。コマンド、送信元、宛先、両端のバージョン、ローカル・NFS・daemon・snapshotの別を記録します。
消えた全パスを別リストに抽出しつつ元ログを残し、親ディレクトリ別に数えます。ロック1件と利用者文書100件は同じ扱いにできません。
所有者と価値で分類する
どのプロセスが作成・改名・削除するか、権威データ、再生成可能なキャッシュ、一時ロック、受信スプール、不明のどれかを確認します。
通常ファイルが繰り返し消えるなら、除外変更の前にマウント、権限、送信元の同一性、遠隔サービスを確認します。
安定した境界で再実行する
可能な範囲で送信元を静止して同じコマンドを再実行します。重要パスが再現するなら偶然扱いを止め、時点スナップショットかアプリ整合エクスポートを使います。
ファイルシステムスナップショットでもアプリ固有のflushやdumpが必要な場合があります。容量を監視し、満杯で無効になる前に対処します。
修復・除外・限定ラッパーを選ぶ
重要または不明なパスなら送信元、マウント、アプリ工程を修復します。再生成可能で文書化された対象だけを除外します。
公式FAQのラッパーは24だけを0へ変えます。監査済みの残存パスがポリシーに合う場合だけ使い、他の非0を成功にしません。
2回の受入試験で閉じる
通常スケジュールと安定した送信元で各1回実行し、総量、パス、状態、宛先検証を記録します。
0は合格。24は完全な承認済み一覧だけで他の診断がない場合に限り合格し、それ以外は失敗を維持します。
