Red Hat EBADFD (77) 対策: “File descriptor in bad state” エラー発生時のディスクリプタ再初期化と対策編

【注意】 本記事は一般的な情報提供です。実際の障害状況・システム構成・再現条件により最適な対処は変わります。重要データや業務影響がある場合は、株式会社情報工学研究所のような専門事業者に相談してください。

　

「またFDか…」現場で起きる“File descriptor in bad state”のモヤモヤから始めよう

深夜のアラートで目が覚めて、ログに出ているのは EBADFD (77) “File descriptor in bad state”。たしかにファイルディスクリプタ（FD）周りのエラーっぽい。でも、いま落ちてほしいのはそこじゃない……という、あの感じ。

「え、FDって整数でしょ？ close 忘れ？ 二重 close？ いや、それなら EBADF じゃない？」
──そう思うのは自然です。むしろ健全な疑いです。

EBADFD は、ざっくり言えば「FDは“存在”しているように見えるのに、そのFDが期待される状態にない」というニュアンスで出てきます。だからこそ、現場の感覚としては “壊れた” というより “なんか変な状態で固まってる” に近い。ここが、初見で腹落ちしにくいポイントです。

---

本番運用の現場では、エラーの意味が曖昧なまま対処が先行しがちです。

• とりあえず再起動して沈静化させる（でも再発する）
• リトライを増やして抑え込みを狙う（でも障害が長引く）
• 原因が掴めず、説明コストだけが積み上がる（つらい）

ただ、EBADFD は「再起動で一時的に収束」しやすい一方で、根っこが残りやすいタイプでもあります。ここで必要なのは、精神論ではなく ディスクリプタのライフサイクルを“状態”として捉え直すことです。

この記事は、いま起きている障害のダメージコントロールから入り、切り分けの最短ルートを示し、最後は「再初期化できる設計」に落とし込むところまで一本の線でつなぎます。読み終えたときに「なるほど、やることが具体化した」と思えるところまで持っていきます。

　

EBADFD(77)は「壊れたFD」ではなく「状態遷移に失敗したFD」だと捉える

まず言葉を整えます。Linuxでは、システムコールが失敗したとき errno に理由が入ります。多くの人が慣れているのは EBADF（Bad file descriptor）でしょう。これは「そのFDは有効ではない（無効・未オープン・すでに close 済み等）」という意味で理解されやすいです。

一方で EBADFD（File descriptor in bad state）は、名前の通り「FDが悪い状態にある」。ここで重要なのは、“FDが存在する/しない”ではなく、“状態が正しい/正しくない”という観点が混ざってくることです。

似ている errno を並べて、違いの勘所をつかむ

errno	典型メッセージ	見立ての方向性
EBADF	Bad file descriptor	FDが無効（管理ミス・寿命切れ・参照違い）
EBADFD	File descriptor in bad state	FDはあるが、前提の状態にない（状態遷移の失敗・競合・境界不整合）
EINVAL	Invalid argument	呼び出し方（引数/フラグ/順序）が前提違い
EIO	I/O error	下層のI/Oが失敗（デバイス/ネットワーク/FSなど）

この表が示しているのは、「EBADFDを見たら、まず “FDの所有権・寿命・状態遷移” を疑う」ということです。ここでいう状態遷移とは例えば、次のようなものです（あくまで一般論です）。

• オープン→利用中→クローズ、の寿命がスレッド間でズレる
• 接続中→切断→再接続、のイベントとアプリの内部状態が一致しない
• 親子プロセスや exec を跨いで「想定外の継承」が起きる

---

ここで伏線を置きます。EBADFD は「たまたま変な値が入った」よりも、「設計上の境界が曖昧」なときに再発しやすい傾向があります。

つまり、対策は2段構えになります。

1. 目の前の障害を鎮火させる（切り分け・再初期化・運用の手順化）
2. 再発しないように“状態”をコードに落とす（責務分離・ライフサイクルの一元化）

次章では、Red Hat系（RHEL系）で「どこで」この問題が目に入りやすいかを、現場で使う観測ポイント（ログ・/proc・strace 等）に寄せて整理します。

　

Red Hat系で遭遇しやすい発火点：glibc / スレッド / 非同期I/O / ドライバ境界の“すれ違い”

最初に強調しておきたいのは、EBADFD(77)は「Red Hat固有の魔法のエラー」ではないことです。RHEL系で見かけやすいのは、多くの場合運用規模（長時間稼働・高並列・複雑な依存）が背景にあって、FDの状態ズレが表に出やすいからです。

“どの層の問題か” を早めに切り分ける

現場では、次のどこでエラーが観測されているかを先に押さえるだけで、迷子になりにくくなります。

• アプリログ：ライブラリが errno を文字列化して出している（元のシステムコールは不明）
• ミドルウェアログ：DB/メッセージング/Proxy等がFD周りの異常として吐く
• strace：実際のシステムコールが errno=EBADFD を返している
• カーネルログ：下層I/Oの異常やドライバ起因の兆候が先に出ている

観測の“最短セット”を用意する（本番のダメージコントロール用）

「また新しいツール？どうせ運用が増えるだけじゃないの」って正直思いますよね。なので、ここでは増やしません。よくある最短の観測セットだけを書きます。

• 対象プロセスのFD一覧：/proc/<pid>/fd と /proc/<pid>/fdinfo（増減・不自然な残骸・ソケットの対応を確認）
• lsof：FDが何に紐づいているかを人間の言葉に寄せる（特にソケット）
• strace -f：どのシステムコールがEBADFDを返したかを確定する（可能なら一時的に）

ここでの狙いは、「原因を特定した」と言い切ることではなく、“どの境界が破綻しているか”を特定することです。例えば、ソケット再接続の境界なら「切断イベント→再接続→FD差し替え」の一連の流れを疑う。スレッド競合なら「closeと利用が競合」していないかを見る。fork/exec なら「継承とクローズ・オン・execの扱い」を疑う、という具合です。

なぜ “非同期” が絡むとややこしくなるのか（一般論）

非同期I/O（イベント駆動、スレッドプール、AIO/リングバッファ系の仕組みなど）では、I/O要求の発行者と完了通知の受け手が時間的に分離します。この分離自体は性能の源泉ですが、同時に「FDの寿命」と「I/Oの寿命」がズレる余地も増やします。

結果として、次のような事故が起きやすいです。

• 再接続でFDが差し替わったのに、古いFDを参照するタスクが残っている
• クローズ済み（またはクローズ予定）のFDに対して、後からI/O完了やイベントが飛んでくる
• 例外経路（タイムアウトやキャンセル）でFDの後始末が抜ける

---

この章の結論はシンプルです。EBADFD を “謎エラー” として扱わず、状態ズレが起きる境界（スレッド/再接続/fork/exec/非同期）を疑うこと。次章では、その中でも再現・再発の頻度が高い「fork/exec とFD継承」の罠を具体化し、設計としてどう歯止めをかけるかまで踏み込みます。

　

典型シナリオ①：fork後の親子でFD管理がズレる（close-on-exec / dup / 継承の罠）

プロセスを fork したり、子プロセスで exec したりする構成は、RHEL系の現場でも珍しくありません。ワーカー生成、外部コマンド実行、ログローテート連携、バックアップ、ヘルスチェックの補助スクリプト……便利な反面、FDの管理がズレる余地が増えます。

“継承されるはず/されないはず” が崩れると、状態が壊れやすい

ポイントは、FDが「整数」だからこそ、見た目が同じでも中身が別物になり得ることです。たとえば親で開いたソケットやファイルが、子に意図せず継承されると、親がクローズしたつもりでも参照が残ります。逆に、子に渡したいFDが close-on-exec（FD_CLOEXEC）で落ちると、子は「あると思っていたFD」を失います。

この手のズレは、最終的に “おかしなタイミングでcloseされる / 参照される” という形で表に出ます。結果として、EBADFだけでなく、状況によっては EBADFD のような「状態異常」系の扱いで観測されることがあります（観測点やライブラリの実装により見え方が変わります）。

よくある “現場あるある” を3つだけ

• 外部コマンド実行：子プロセスに不要なFDが残り、親のリソースが解放されない（リーク/枯渇）
• dup/dup2 の扱い：リダイレクトのつもりが、元FDのクローズ順序を誤って参照ズレ
• ログ/ソケットの共有：親子で同じFDを触り、クローズの責務が曖昧になる

設計上の歯止め：FDの責務を“1箇所”に寄せる

「それ、誰がメンテするの？」ってまず考えるのが現場だと思います。なので、ここは運用しやすい方向に寄せます。

歯止めの基本は、FDを扱う責務を薄くして、境界を明確にすることです。

• 子に渡す必要があるFDだけを明示し、それ以外はexec前に閉じる（“閉じるのが既定”）
• close-on-exec の方針を決め、例外だけ解除する（“残すのは例外”）
• FDの所有者（owner）をコード上で一意にする（誰がcloseするか）

---

ここで次の章への伏線を置きます。fork/exec のズレは「構造」で起きますが、スレッド・シグナルのズレは「タイミング」で起きます。そして本番で厄介なのは、構造とタイミングが重なるケースです。次章では、スレッドとシグナル、そして close 競合がどう “FDの状態” を壊し得るかを整理し、再初期化（作り直し）を前提にした安全な作り方へ進みます。

　

典型シナリオ②：スレッドとシグナルの競合で「使っていいはずのFD」が壊れる

マルチスレッド化されたサービスでは、「FDは共有資源」という現実から逃げられません。アプリの都合でスレッドが増え、ライブラリの内部でもスレッドが動き、さらにシグナル（SIGTERM / SIGALRM など）が割り込む。ここで事故が起きる典型は、“close と利用が競合する”パターンです。

現場でよく聞くのは、こういう声です。

「クローズはちゃんと書いてる。なのに“bad state”って何？」

このモヤモヤの核心は、プログラム上は「順番通り」に見えても、実行時には タイミングがズレることです。例えば次のような流れは、特別なことをしていなくても起き得ます。

• スレッドA：I/O待ち（read/poll/epoll 等）
• スレッドB：タイムアウトや再接続ロジックで FD を閉じる／差し替える
• スレッドA：復帰した瞬間に “古いFD” へアクセスし、想定外のエラーを引く

---

「EBADF」だけでなく「EBADFD」として見える理由

EBADF は「無効なFD」というイメージが強い一方、EBADFD は “FDが悪い状態” と表現されます。LinuxではEBADFDは errno のひとつとして定義されており、RHEL系を含む一般的なLinux環境では EBADFD が 77として割り当てられています。

ただし、実運用で見えるメッセージは「どの層が errno を文字列化したか」に依存します。ライブラリが内部状態を見て EBADFD として返す場合もあれば、別の層では EBADF として扱われる場合もあります。ここが“同じ現象に見えるのにログが揺れる”原因になりがちです。

---

ダメージコントロールの第一歩：FD操作を「単一の窓口」に寄せる

競合をゼロにするのは難しくても、競合が起きても破綻しない形にはできます。要点は「FDを触る場所を増やさない」ことです。

• クローズ/再接続/差し替えは1つの管理モジュールに集約する
• 他のスレッドは「FDそのもの」を持たず、管理モジュール経由でI/Oする（参照を間接化）
• どうしてもFDを渡すなら、渡す側・受け取る側の双方で寿命（所有権）を明文化する

「また設計を変えるの？」と思うのは自然です。だからこそ、次章では“設計変更を最小化しつつ”現場で頻出のネットワーク断・再接続の罠を整理し、FDの再初期化（作り直し）へ自然に接続していきます。

　

典型シナリオ③：ネットワーク断・再接続でソケット状態だけが先に死ぬ（アプリは生きてる顔）

EBADFD(77) が“現場で一番つらい形”で出るのは、ネットワーク越しのI/Oです。DB、メッセージキュー、外部API、ストレージ、プロキシ……。ネットワークが一瞬揺れただけでも、ソケットの状態は変化します。でもアプリ側は「まだ行けるはず」と思ってしまう。このズレが、障害の長期化につながります。

ここで重要なのは、ネットワーク断そのものよりも、断の後の状態遷移です。典型的には次の2つが起きます。

• ソケットはすでに破綻しているのに、アプリは“同じFD”に対してI/Oを続けようとする
• 再接続で新しいソケットへ差し替えたのに、どこかの処理が古いFDを握り続ける

---

「リトライを増やせば沈静化する」とは限らない

現場でありがちなのは「とりあえずリトライ回数を増やして抑え込みたい」という判断です。短期的には鎮火に寄与する場合もありますが、FDが“悪い状態”に落ちているときに機械的リトライを続けると、次の副作用が出やすくなります。

• 同じFDに対する無駄なI/Oが増え、CPU/スレッド/キューを圧迫する
• タイムアウトが連鎖し、別系統の処理まで巻き込んで温度が上がる
• 復旧のための再接続・再初期化が遅れ、結果的に復旧が長引く

ここで必要なのは「粘る」のではなく、壊れている（または壊れた可能性が高い）FDを捨てる判断です。つまり、リトライの前に「健全性チェック」を入れて、ダメならFDを作り直す（再初期化する）。この方が被害最小化につながることが多いです。

---

再接続設計で押さえるべき“最低限の3点”

ネットワーク断は避けられない前提として、再接続周りは次の3点を「仕様」にしておくと、EBADFD系の長期化を防ぎやすくなります。

1. FD差し替えの原子性：差し替え中に古いFDへアクセスさせない
2. 古いFDの無効化通知：参照者に「もう使うな」を確実に伝える
3. 再試行の上限と待機：無限リトライでも “間隔” と “回路遮断” を設計する

この3点は、言い換えると「状態機械（ステートマシン）を持て」という話です。次章では、実際に本番で“何を見て”“どこまで確度を上げるか”を、strace / lsof / /proc の観測に落として、切り分けの最短手順を整理します。

　

いきなり再起動しない：本番でできる“切り分け最短手順”（strace / lsof / /proc）

「再起動すれば収束するかも」──その判断が現実的な場面はあります。ただし、毎回それで済ませると、再発のたびに同じ夜が来ます。ここでは、運用負荷を増やしすぎずに実施できる“最短セット”をまとめます。目的は犯人探しではなく、どの境界が破綻しているかを特定して、再初期化の設計へつなぐことです。

手順0：いま見えている「EBADFD(77)」が本当に errno 由来か確認する

ログに「EBADFD(77)」と出ていても、アプリ独自コードの可能性があります。まずは「errno の文字列化」かどうかを確認します。Linuxでは EBADFD は “File descriptor in bad state” として定義されています。

もしライブラリが errno を出しているなら、同じプロセスで別のエラーにも errno の定型表現が出ていることが多いです（例：EPIPE, ECONNRESET 等）。ここで「errno系列のログ」である確度を上げます。

---

手順1：/proc で「そのプロセスが握っているFD」を把握する

対象PIDが分かるなら、まずは /proc を見ます。/proc は追加導入が不要で、現場のダメージコントロールに向いています。

• /proc/<pid>/fd/：FD一覧（どの番号が何を指すかのシンボリックリンク）
• /proc/<pid>/fdinfo/：オフセットやフラグなど補助情報

ここで見るべき観点は次の通りです。

• FD数が異常に増えていないか（リークやクローズ漏れの疑い）
• ソケットFDが大量に残っていないか（再接続失敗や参照残りの疑い）
• 特定FDが繰り返し生成・破棄されていないか（リトライが暴走していないか）

---

手順2：lsof で「FDの中身（相手先）」を人間の言葉に寄せる

/proc は強いですが、読み解きに慣れが要ります。lsof を使うと「それが何か」を素早く言語化できます。特にネットワーク越しのI/Oでは、相手先（IP/port）を掴めるかどうかが大きいです。

例としては、次のような観測が役立ちます。

• 同一の宛先に対してソケットが増殖している（再接続の抑え込みに失敗）
• CLOSE_WAIT が残り続ける（相手側クローズとアプリ側の後始末が不整合）
• UNIXドメインソケットやパイプが大量に残る（ワーカー/子プロセス境界の疑い）

---

手順3：strace で「どのシステムコールが EBADFD を返したか」を確定する

最短で腹落ちさせるのは、EBADFDを返したシステムコール名を押さえることです。同じ “File descriptor in bad state” でも、read系か、poll系か、fcntl系かで見立てが変わります。

strace は負荷影響があり得るため、常時ではなく短時間で使うのが基本です。可能なら、再現しやすいタイミングや限定的なプロセスで実施します。

観測結果から「次の一手」を決める対応表

観測	示唆	次の一手
EBADFDが read/recv で発生	ソケット/FDの寿命とI/Oがズレている疑い	健全性チェック→NGならFD再初期化（差し替え）を優先
EBADFDが poll/epoll 後に発生	イベントと実FDが一致していない疑い（参照残り）	FD管理窓口の一元化、登録解除と差し替えの原子性を点検
FD数が増え続ける	リーク/クローズ責務の曖昧さの疑い	所有権（誰がcloseするか）を設計・実装で固定する

---

ここまでで「どの境界が破綻しているか」が見えれば、あとは“場を整える”段階です。次章では、いよいよ本題である ディスクリプタ再初期化（FDを捨てて作り直す）の具体パターンを整理し、リトライや回路遮断（ブレーキ）を含めた実装方針に落とし込みます。

　

再初期化パターン：FDを捨てて作り直す設計（リトライ、回路遮断、健全性チェック）

ここからが「具体的にどう直すか」です。EBADFD(77)が出たとき、現場で一番やりがちなのは“同じFDに対して同じ操作を繰り返す”ことです。ですが、EBADFDが示唆しているのは「そのFDが期待される状態にない」ことなので、同じFDに同じ操作を繰り返しても収束しない（むしろ温度が上がる）ケースが多いです。

そこで基本方針は、次のように割り切ります。

• EBADFD が出たFDは、その場で見切りをつける（同一FDへの粘りをやめる）
• 健全性チェック → 失格なら再初期化（FDをcloseし、新しいFDを作る）
• 再初期化は「手順化」する（場当たりにせず、回路遮断＝ブレーキも含める）

---

まず「健全性チェック」を決める（チェックに時間をかけすぎない）

健全性チェックは、万能を狙うほど運用コストが増えます。現場で使うなら、短く、負荷が低く、判定が明確なものに寄せます。一般的な考え方としては次の通りです（対象がソケットか、ファイルかで手段は変わります）。

• ソケット：エラー状態の取得、送受信の最小確認、イベント登録の整合性確認
• ファイル：オープンフラグや位置、利用スレッドとの所有権整合性の確認
• 共通：そのFDが「いまの状態機械のどこにいるべきか」を確認し、逸脱なら失格

ポイントは「テストに落ちたら“捨てる”」ことです。捨てる判断ができないと、いつまでも抑え込みの泥沼になります。

再初期化の手順を“コードとして固定”する

再初期化は、やること自体は単純に見えます。ですが、現場で問題になるのは「差し替えの途中で古い参照が残る」「再初期化が同時多発して雪崩れる」などの二次災害です。そこで、再初期化の手順は次のように固めます。

1. 差し替えを宣言：管理モジュールが「いま差し替え中」と状態を立てる
2. 参照を止める：他スレッドが古いFDでI/Oしないようにブロック/無効化する
3. 古いFDを閉じる：クローズ責務は必ず管理モジュールに寄せる
4. 新しいFDを作る：接続/オープンの失敗は“再試行”へ
5. イベント再登録：epoll等を使うなら登録解除→登録を確実にやり直す
6. 差し替え完了：状態を戻し、参照を再開する

「回路遮断（ブレーキ）」がない再試行は、障害を長引かせる

「再接続の無限リトライ」は、現場ではよく採用されます。ただ、無限リトライは“頻度”を誤ると、相手系や自分のリソースを削り、結果的に復旧を遅らせます。だから、無限リトライをするなら次の2点はセットで入れます。

• バックオフ：待機時間を段階的に増やす（例：1s→2s→5s→10s…）
• 回路遮断：一定回数失敗したら、しばらく“呼び出し自体を拒否/縮退”する

これがあるだけで、「リトライ嵐でCPUが燃える」「ログが洪水になる」「観測ができない」という状況を被害最小化できます。現場の“空気を落ち着かせる”には、こういうブレーキが効きます。

実装の型（疑似コード）：参照を間接化して差し替える

言語に依らない考え方として、FDを直接配るのではなく「管理オブジェクト経由でI/Oする」形に寄せます。

// 擬似コード（言語非依存のイメージ） manager = ConnectionManager()
function safe_io(request):
conn = manager.get_current() // 直接FDを握らない
if !conn.is_healthy():
manager.reinit_with_backoff() // 健全性NGなら再初期化（差し替え）
conn = manager.get_current()

return conn.do_io(request) // I/Oは常に管理下の接続に対して行う

// 再初期化は一度に一人がやる（同時多発を避ける）
function reinit_with_backoff():
if !try_lock_reinit(): return // すでに誰かが再初期化中なら待つ/戻る
set_state(REINITING)
close_old_fd_safely()
for attempt in range(1..N):
fd = open_or_connect()
if success:
register_events(fd)
swap_current(fd) // 差し替えは原子操作として扱う
set_state(READY)
unlock()
return
sleep(backoff(attempt))
set_state(DEGRADED) // 縮退（回路遮断）
unlock()

この型を持つと、EBADFDが出たときに“同じFDにしがみつく”のではなく、設計として「作り直す」が自然な挙動になります。次章では、さらに一段上げて、そもそもEBADFDが起きにくい構造（状態機械・責務分離・テストの置き方）に落とします。

　

予防パターン：FDライフサイクルを「状態機械」に落とし、境界を1つに寄せる

再初期化パターンは“効く”のですが、毎回それだけだと「なぜそれが起きるのか」の説明が弱くなります。上司や役員への説明で詰まるのは、だいたいここです。

「で、結局また起きるの？起きないの？どこまで責任を持てるの？」

この問いに答えるには、FDの扱いを“気合い”から“仕様”に変える必要があります。具体的には、FDのライフサイクルを状態機械（ステートマシン）として定義し、境界を1つに寄せます。

---

状態機械に落とすと、説明と実装が揃う

FD（特にソケット）を例にすると、最小でも次のような状態が必要になります。

• INIT：未接続（まだFDを持たない）
• CONNECTING：接続試行中（差し替え中）
• READY：利用可能（I/Oしてよい）
• FAULT：異常検知（EBADFD/EPIPE/ECONNRESET 等を含む）
• REINITING：再初期化中（参照停止）
• DEGRADED：縮退運転（回路遮断、限定機能のみ、など）

これを持つと、例えば EBADFD が出た瞬間に「READY→FAULT→REINITING→READY」という遷移を起こす、と説明できます。現場の腹落ちとしては「謎の例外」ではなく「仕様通りの遷移」になる。これが強いです。

境界を1つに寄せる（FDを触る人を増やさない）

EBADFDが再発しやすい構造は、だいたい次の特徴を持っています。

• FDをcloseする箇所が複数ある（例外経路やタイムアウト経路で増殖）
• FDを握るスレッドが多い（参照が散らばる）
• 再接続・再初期化が“どこからでも起こせる”（同時多発しやすい）

対策は逆で、FD操作の窓口を1つに寄せることです。すると、やるべきレビューもテストも集約できます。

テストと検証の置き方：再現が難しいなら“壊してみる”

EBADFDは再現が難しいことが多いです。だからこそ、テストは「正常系」ではなく「壊れ方」を入れます。現場で効くのは、次のような検証です。

• ネットワーク断（切断、遅延、パケットロス）を人工的に作り、再接続が仕様通りに動くか
• 再初期化が同時多発しても、再初期化が一人に収束するか（ロック/排他の確認）
• 縮退（DEGRADED）に入ったときのユーザ影響が制御できているか（被害最小化）

この段階でのゴールは「二度と起きない」と断言することではありません。ゴールは、起きたときに議論が過熱しない状態――つまり「起き方が想定内で、復旧手順が決まっていて、説明できる」状態に持っていくことです。

---

次章では、ここまでの伏線を回収します。EBADFD(77)を“その場しのぎ”で終わらせず、運用・設計・説明責任をまとめて整え、最終的に「一般論の限界」と「個別案件の相談先」を自然に結びます。

　

帰結：EBADFD(77)を“個別対処”で終わらせず、運用と設計で再発を収束させる（相談先も含めて）

EBADFD(77)に対して、ここまでの話を一言でまとめるならこうです。

「悪いFDを握り続けない。状態遷移として扱い、作り直せる設計にする」

現場の感覚としては「また例外かよ…」ですが、技術的には“例外が起きること自体”は避けられません。避けるべきは、例外が起きたあとに、

• 無限リトライで温度が上がる
• 説明できず、社内調整・対人コストが膨らむ
• 根治できないまま同じ障害が繰り返される

という構図です。つまり、目指すべきは「ゼロ」ではなく「収束」です。

---

運用（Runbook）として最低限そろえるべきもの

設計が良くても、現場で動かなければ意味がありません。EBADFD系の障害を鎮火させるために、最低限次を“運用の型”として持っておくと、復旧が早くなります。

• 観測の最短手順（/proc, lsof, strace の使い分け）
• 「同一FDへの粘り」をやめる判断基準（健全性NG→再初期化）
• 回路遮断（ブレーキ）と縮退運転（DEGRADED）への移行条件
• 再発時の説明テンプレ（状態機械の遷移として説明できる形）

設計として最低限そろえるべきもの

• FD操作の窓口を1つに寄せる（close/差し替え/再接続の責務一元化）
• 状態機械を定義し、遷移がコードに現れるようにする
• 再初期化は一人が行う（同時多発の抑え込み）
• バックオフと回路遮断を標準装備する（被害最小化）

---

一般論の限界：ここから先は「あなたの環境」で変わる

ここで正直な話をします。同じEBADFD(77)でも、原因は環境で変わります。

• OSのバージョン、カーネル、glibc、ドライバ、仮想化基盤
• ミドルウェア（DB/Proxy/Queue）とその設定
• 接続先の挙動（タイムアウト、切断、キープアライブ、負荷）
• あなたのアプリの並列モデル（スレッド、イベントループ、fork/exec の有無）

つまり「これをやれば絶対に直る」という万能薬はありません。だからこそ、現場で本当に必要なのは、障害を“鎮火”させつつ、再発を“収束”させるための個別最適です。

次の一歩：具体案件の“診断”を短時間で前に進める

もしあなたが、

• 再起動で一旦は落ち着くが再発している
• 再接続・再初期化が絡み、説明が難しい
• 影響範囲が広く、ブレーキの入れ方（縮退運転）が決めきれない

という状況なら、一般論の読み合わせよりも、観測点の設計（どのログ・どの指標・どのトレースを取るか）と、再初期化の実装方針（窓口一元化・状態機械・回路遮断）を、あなたのシステム構成に合わせて短時間で組み立てる方が早いです。

株式会社情報工学研究所では、データ復旧だけでなく、障害対応の現場で必要になる「切り分けの手順化」「再発を収束させる設計」「説明可能な運用」を、個別案件として一緒に整理できます。業務影響が出ている、または重要データ・重要サービスが絡む場合は、早い段階で専門家に相談することが結果的に被害最小化につながります。

　

付録：主要プログラム言語ごとの「FD再初期化・所有権・並列」の注意点

最後に、現在よく使われる言語ごとに「EBADFD(77)系の障害が長引きやすい落とし穴」を整理します。ポイントは、言語の優劣ではなく資源（FD）の所有権と並列モデルです。

C / C++

• 所有権が散りやすい：FDを裸で持ち回す設計は、close競合や二重closeを招きやすい
• 例外経路の後始末：エラー分岐が増えるほどクローズ漏れが起きやすい。RAII（スコープで確実に解放）に寄せる
• fork/exec境界：FD_CLOEXECの方針が曖昧だと、継承ズレが起きやすい

Rust

• 所有権は強いが境界設計が重要：安全に見えても、非同期タスク間で“参照の生存期間”を誤るとロジックが破綻する
• 再初期化の一元化：接続オブジェクトを共有する場合、差し替えの原子性（swap）と排他は設計で固定する

Go

• ゴルーチンの同時多発：再接続・再初期化が複数ゴルーチンから同時に走りやすい（雪崩れ）
• Context / Timeout：タイムアウト・キャンセル時の後始末（close、登録解除）が設計の要点になる
• netパッケージ依存：I/O失敗時に同一コネクションへ粘るより、作り直す方針を明確にする

Java / Kotlin（JVM）

• “FDを直接触らない”ぶん見えにくい：例外は抽象化されるが、根はソケット/FDの寿命ズレであることが多い
• スレッドプールと再試行：リトライがスレッド枯渇やキュー詰まりを招き、障害が拡大しやすい
• 接続プール：プールの健全性判定と破棄（evict）が弱いと、不良接続が残り続ける

Python

• 例外で流れる：例外処理に頼りすぎると、再初期化の責務が散らばる。管理窓口に寄せる
• asyncio/スレッド混在：イベントループとスレッドを跨ぐと、差し替えのタイミングズレが起きやすい
• with文は強い：ファイルやソケットのクローズ漏れを減らす。だが再接続の状態機械は別途必要

Node.js（JavaScript）

• イベントループは強いが“再接続嵐”に弱い：短間隔リトライは一気に負荷を上げる
• Promise/イベントの二重発火：切断イベント・タイムアウト・例外が重なると二重で再初期化が走りやすい
• バックオフと回路遮断：被害最小化のため、標準で入れておくと運用が安定する

Ruby

• 抽象化の裏でFDが増える：プロセス/スレッド/外部コマンド実行を混ぜると継承ズレやクローズ漏れが起きやすい
• 再試行の設計：例外→rescue→retry の乱用は、抑え込みに見えて障害長期化の原因になる

PHP

• 長期常駐（ワーカー）で顕在化：FPM/ワーカー常駐や外部I/Oが増えるほど、接続の健全性と破棄設計が重要になる
• エラー握りつぶし：ログが薄いと切り分けが遅れる。観測点（失敗理由）を残す設計が必要

C# / .NET

• IDisposable の徹底：Dispose漏れは資源枯渇につながる。責務の一元化とスコープ管理が重要
• async/await：キャンセルやタイムアウト時の後始末が分散しやすい。再初期化の窓口を固定する

---

どの言語でも共通する結論は同じです。EBADFD(77)は「そのFDに粘る」より「状態として扱って作り直す」方が収束しやすい。そして、その作り直しを“場当たり”ではなく“仕様”に落とすことが、運用の温度を下げ、説明を楽にし、被害最小化につながります。

ただし、どの程度まで再初期化・縮退を入れるべきかは、あなたのシステムのSLA、依存先、トラフィック特性、データの重要度によって変わります。一般論だけで決めると、別のリスク（過剰な遮断、過剰なリトライ、性能劣化）を招くこともあります。

具体的な案件・契約・システム構成の前提がある場合は、株式会社情報工学研究所のような専門家に相談し、観測点と復旧方針を一緒に設計しておくのが安全です。そこまで整えると、次に同じエラーが出ても「議論が過熱する」のではなく、「手順通りに鎮火・収束させる」運用に寄せられます。