テクノロジー · 実用ガイド
curl エラー23：再試行の前に出力先の消費側を特定する
エラー23は、受信データをローカルの出力先へ書き込めなかったことを示す。stderrとパイプ各段の状態を保存し、ファイル、パイプ、端末、コールバックのどれが失敗したかを直してから、完全なバイト数や信頼できるダイジェストで検証する。
curlの終了コード23はローカル書き込み失敗であり、ネットワーク障害の診断名ではない。stderrと全パイプ段の状態を保存し、実際の出力消費者を特定して書き込み契約を再現し、修復後に完全なバイト数または信頼できるダイジェストで合格判定する。
1. 再試行前に最初の失敗を保存
stderrを隠さない最小の同等コマンドで再現する。直接ファイルならコマンド、正確なパス、curl終了コード、最初の書き込みエラーを記録し、パイプなら直後にBashのPIPESTATUSを保存して必要に応じpipefailを有効にする。
最初に再試行追加、stderr破棄、TLS変更をしない。23はローカルファイルシステム等への書き込み失敗であり、再試行では親ディレクトリ、空き容量、閉じたパイプ、コールバック戻り値を直せない。
2. 失敗した書き込み先を特定
-oのファイルでは親、権限、空きブロックとinode、クォータ、マウント、名前空間を確認する。stdoutがパイプなら次のプロセスが消費側で、意図的終了、クラッシュ、拒否を区別する。端末やlibcurlコールバックも同じく出力先だ。
コールバックは処理した全バイト数を返す必要がある。短い戻り値や失敗はCURLE_WRITE_ERRORとなるため、要求量、戻り量、アプリのエラーを記録する。
3. リモートではなくローカル出力先を再現
無害な既知入力で消費側だけを試す。curl 8.5.0のローカル試験では/dev/full、存在しない親、head -c 1への完全ストリームがcurl 23となり、sha256sumへ最後まで渡した場合は両段とも0だった。
headの早期終了は先頭だけ必要なら意図的だが、完全ダウンロードとは呼ばない。インストーラ、アーカイブ、データ取込では消費側と完全性確認が通るまで失敗として扱う。
4. 所有者を修復して合格条件を定義
証明した分岐を修復する。正しい親と所有者を作成し、容量を確保し、書込み可能なマウントを戻し、下流やコールバックを直す。変更後も同じ証拠を再取得する。
メッセージ消失だけでは不十分だ。curlと必要な全消費側の状態、正しい名前空間の出力、可能なら長さ、配布元ダイジェストまたは署名を確認し、元のstderrと最終検証を一緒に残す。
