CentOS EBADF (9) 対策：無効ファイルディスクリプタエラー「Bad file descriptor」発生時の再設定対策編

【注意】本記事の内容は、CentOS を含む一般的な Linux 璦境で発生する EBADF（Bad file descriptor）エラーについて、公開されている技術仕様や一般的な運用ナレッジを整理したものです。実際のシステム構成・契約条件・社内規程などによって最適な対応は異なります。重要な業務システム・医療機関・公共インフラなどの環境では、必ず社内の責任者や株式会社情報工学研究所、の個別診断を踏まえて対応方針を決定してください。

　

とりあえず再起動で流してきたEBADFとちゃんと向き合う

CentOS を運用していると、ログにぽつぽつと現れる EBADF (Bad file descriptor)。多くの現場では、サービスを再起動したり、最悪サーバーごと再起動したりして「とりあえず症状は消えたから良し」と扱ってきたケースが少なくありません。

エンジニアの心の中では、こんな独り言が聞こえているはずです。

• 「ファイルディスクリプタが変になるなんて、普通はありえないはずなんだけどな…」
• 「たぶんどこかで二重 close してるんだろうけど、掘るとキリがなさそう」
• 「夜間障害で呼び出されるくらいなら、定期再起動で“なんとなく安定”させておきたい」

この感覚自体は、とても自然です。業務システムは止められませんし、「根本原因の究明」よりも「今動かすこと」が優先される場面は確かにあります。ただし EBADF が出ているという事実は、「いまはたまたま動いているが、本来想定していないパスで I/O が流れている」という、かなり強いシグナルでもあります。

Linux カーネルや glibc の挙動に基づくと、EBADF はおおざっぱに言えば「そのファイルディスクリプタ番号は、今のプロセスにとって有効ではない」という意味です。言い換えれば、プロセス内部のリソース管理ロジックとカーネル側の現実がずれている状態であり、メモリ破壊・ハンドルリーク・誤ったライフサイクル管理など、より重いバグの表面症状になっていることもあります。

再起動で一時的に症状が消えてしまうと、「やっぱり OS 側の不機嫌だったのかな」と片付けたくなりますが、実際には以下のような伏線が張られていることが多いです。

• ログローテートや設定変更のタイミングでのみ EBADF が出る
• 複数プロセス・複数スレッドで同じ FD を共有している
• systemd のサービス定義とアプリケーション側の FD 取り扱いにズレがある
• 本番環境だけ LimitNOFILE や ulimit が異なり、テストでは再現しない

こういった伏線を放置したまま「再起動でリセットする」運用を続けると、いつか別のタイミングでより重大な形（データ損失、ログ欠損、ハングなど）で表面化するリスクがあります。本記事では、CentOS を例にしながら、EBADF を「再起動で流す現象」から「設計と運用を見直すトリガー」へと位置づけ直すことをゴールにします。

第1章では、あえて感情面のモヤモヤを言語化しました。次章からは、「そもそもカーネルは EBADF で何を伝えようとしているのか」を、仕様ベースで整理していきます。ここを押さえることで、その後の調査や再設定が一本の線でつながるようになります。

　

「Bad file descriptor」がカーネルからのどんな警告なのかを言語化する

まずは事実関係を整理します。Linux を含む POSIX 的な OS では、多くのシステムコールが次のような戻り値の規約を持っています。

• 成功時：0 以上の値（読み取ったバイト数など）
• 失敗時：-1 を返し、errno にエラーコードを設定

EBADF は、その errno の一種であり、典型的にはヘッダ <errno.h> で定義されています。多くの Linux 環境では数値として 9 が割り当てられていますが、アプリケーションからは名前（EBADF）で扱うのが一般的です。

マニュアルページ（例：man 2 read や man 2 write）を見ると、read(2) / write(2) / close(2) / dup(2) などのシステムコールに対して、EBADF の説明は概ね次のように書かれています。

• 指定したファイルディスクリプタが開かれていない
• 要求した操作に対して、ファイルディスクリプタのモードが不適切（例：読み込み専用 FD に対する write）

つまり、プロセス側が「有効であるはず」と思い込んで渡した FD が、カーネル側から見ると「すでに閉じられている」か「そもそもそんな FD は知らない」状態だときに EBADF が発生します。ここには明確に、「アプリケーション側の状態モデルとカーネル側の現実が食い違っている」というメッセージが含まれています。

現場でよく聞く本音はこんな感じでしょう。

「いやいや、そんなに FD を触っているわけじゃないし、ライブラリに任せている部分も多いから、正直どこで閉じたかなんて追えないよ」

この感覚も、やはり自然です。最近のアプリケーションは、下記のように多層構造になっていることが多く、close(2) を直接呼んでいるのはごく一部のコードに過ぎません。

• アプリケーションコード（ビジネスロジック）
• フレームワークや ORM、HTTP ライブラリ
• ランタイム（例：JVM、Python インタプリタ、Ruby VM など）
• 標準ライブラリ（glibc など）
• カーネル

どこか1か所でもライフサイクル管理が破綻すると、結果として最上位のアプリケーションが「意図しない EBADF」を受け取ることになります。特に CentOS のようなディストリビューションでは、標準ライブラリや systemd のバージョンも含めた「組み合わせ」が本番環境ごとに異なり、「テストでは出ないが本番だけ EBADF」ということも珍しくありません。

ここまでをまとめると、次のように整理できます。

観点	意味
エラーコード	EBADF（多くの Linux では 9）
典型的なメッセージ	Bad file descriptor
カーネルの主張	「その FD は、今のプロセスから見ると有効ではない」
アプリ側の状態	「有効だと思い込んで使っている」可能性が高い
本質的な問題	リソースのライフサイクル管理（生成・共有・破棄）の破綻

第2章では、あくまで仕様レベルの話にとどめました。次章からは、この抽象的な定義が、現実のコードやマルチプロセス環境でどのような形のバグとして現れるのかを、典型パターンごとに整理していきます。ここを押さえることで、自分の環境で起きている EBADF が「どのカテゴリに属するのか」を切り分けやすくなります。

　

二重close・寿命切れFD・マルチプロセスで起こる典型的な破綻パターン

EBADF の定義が分かったところで、「実際の現場でどういうコードを書くと EBADF を踏むのか」をパターンとして整理します。ここでは、Linux / CentOS 環境で一般的に知られている典型パターンのみを扱い、想像上の特殊事例は取り上げません。

1. 二重 close（same FD を2回以上閉じる）

もっとも古典的で分かりやすいのが「二重 close」です。C の世界では次のようなイメージです。

int fd = open("file.log", O_WRONLY | O_CREAT | O_APPEND, 0644); if (fd == -1) { /* エラーハンドリング */ }

/* 何らかの処理 */

close(fd); /* 1回目の close は OK /
close(fd); / ここで EBADF が発生する可能性がある */

もちろん、多くの場合はコンパイラやレビューで気付けるレベルのミスです。しかし、実際の大規模コードでは次のような形で紛れ込みます。

• エラー処理と正常処理の両方で同じ close() を呼んでしまう
• ラッパ関数内と呼び出し元の両方で close() している
• スレッド間で FD を共有し、一方が close したことを他方が知らない

「自分は close() を直接書いていない」という場合でも、ライブラリ内部やガーベジコレクタが FD を閉じていることがあります。そのため、アプリケーションコードで「念のため close() しておく」といった処理を追加すると、結果的に二重 close になることがあります。

---

2. 寿命切れ FD（構造体やクラスのライフサイクルミス）

次に多いのが「オブジェクトの寿命は終わっているのに、FD の番号だけがどこかに残っている」ケースです。典型的には下記のような形です。

• 一時的な接続オブジェクト（ソケット、パイプなど）を構造体に保持していた
• その構造体が破棄される際に FD を閉じる
• しかし、別の場所にその FD 番号だけがコピーされており、後から使われる

この場合、FD 番号自体は単なる整数ですので、メモリ上に残り続けます。しかし、カーネル側ではすでにその FD が再利用されている場合もあり、「まったく別の資源」を指している可能性すらあります。結果として、次のような現象が起き得ます。

• EBADF が発生する（FD がすでに閉じられている）
• 別のファイルやソケットに対して書き込んでしまう（論理的な事故）

後者はエラーコードとしては表面化しないため、ログの欠損やデータ不整合といった形で長期的にシステムを蝕むことがあります。EBADF が出ているうちはまだ「検知可能なバグ」であるとも言えます。

---

3. マルチプロセス・マルチスレッド環境での共有ミス

CentOS でよく使われる Web サーバー・アプリケーションサーバー・ワーカー型の常駐プロセスでは、fork() やスレッドプールを用いて処理を並列化していることが多くあります。このような環境では、次のようなパターンで EBADF が発生します。

• 親プロセスが子プロセス用の FD をあらかじめ開き、fork() でコピー
• 子プロセス側は「自分には不要な FD 」を close() で積極的に閉じる
• 一方で、親プロセス側もリソース解放のタイミングで同じ FD を閉じる

「どのプロセス／スレッドがどの FD を所有しているか」というルールが曖昧なまま実装されると、二重 close や寿命切れ FD の温床になります。特に、ログファイル・UNIX ドメインソケット・名前付きパイプなどはプロセス間で共有されやすく、EBADF の原因になりがちです。

ここでよくある本音は、

「この FD、本当は誰が責任持って閉じるべきなんだっけ？ もう分からなくなってきた…」

というものです。所有権のルールを設計時にきちんと決めておかないと、コードレビューやテストだけでは抜け漏れを防ぎ切れません。

---

4. 標準入出力や systemd 経由の FD を誤って閉じる

CentOS 7 以降では、systemd によってサービスが起動されるケースが一般的です。systemd は、サービスプロセスに対して標準入力・標準出力・標準エラー出力（FD 0, 1, 2）に加え、socket ユニット経由で渡されるリッスンソケットなど、いくつかの FD を事前に開いて渡すことがあります。

サービス実装側がこれらの FD を「自前で開いたもの」と誤解して close() してしまうと、ログが出力されなくなったり、systemd 側の監視がうまく動かなくなったりします。その後、アプリケーションが別のファイルを開くことで FD 0,1,2 が再利用され、結果的に「予想外の場所にログが書かれる」といった現象も起こり得ます。

この状況で write(2) やライブラリ経由の I/O を行うと、EBADF やその他の I/O エラーが発生し、本来の障害とは別のノイズとしてログに混ざってしまいます。

---

ここまでで、EBADF の代表的な「破綻パターン」が見えてきました。

• 二重 close
• 寿命切れ FD の再利用
• マルチプロセス／マルチスレッドの所有権ミス
• systemd など外部から渡された FD の扱いミス

次章では、これらのパターンを実際に自分の環境で切り分けるために、strace / lsof / /proc を使って「EBADF に至るまでのシナリオ」を事実ベースで再現し、どこで FD のライフサイクルが破綻しているのかを追い込む手順を整理します。

　

strace / lsof / /procでEBADF発生までのシナリオを再現して追い込む

EBADF の典型パターンを把握したところで、「自分の CentOS 環境で起きている EBADF がどれに当たるのか」を、客観的な証拠をもとに切り分けていきます。ここでは、Linux で広く使われている標準的なツールに限定して手順を整理します。

1. strace で「どのシステムコールが EBADF を返しているか」を特定する

strace は、プロセスが実行するシステムコールと、その戻り値・errno を観察するためのツールです。CentOS であれば yum や dnf 経由でインストールできます。

すでに動いているプロセスにアタッチする場合は、次のようなコマンドが典型です。

strace -f -p <PID> -o /tmp/ebadf_trace.log 

• -f：子プロセスも追跡する
• -p <PID>：対象プロセスにアタッチする
• -o：出力先ファイルを指定する

取得したログを検索すると、例えば次のような行が見つかるはずです。

write(5, "....", 123) = -1 EBADF (Bad file descriptor) 

この1行から分かる事実は、

• プロセスは FD 5 に対して write() しようとした
• カーネルは「FD 5 は無効」と判断し、EBADF を返した

ここまで特定できれば、「FD 5 がどのタイミングで開かれ、どこで閉じられたのか」を時系列で追うことができます。同じ strace ログ内で open(...)=5 や accept(...)=5 を探し、そこから先の close(5) まで追跡します。この過程で、二重 close や予期しないタイミングでの close が見えてくることがあります。

---

2. lsof /proc/<PID>/fd で「今開いている FD の一覧」を見る

lsof は、プロセスごとのオープンファイル一覧を確認するためのツールです。例えば、対象プロセスの PID が 1234 の場合、次のようなコマンドが使えます。

lsof -p 1234 

出力には FD 番号・種別（ファイル、ソケットなど）・パスなどが表示されます。strace で EBADF を確認した FD 番号（例：5）について、

• 現時点で lsof に出ているか？
• 出ている場合、その FD は何を指しているか？（ログファイル、ソケットなど）

を確認することで、

• 「すでに閉じられており、lsof にも出ていない」 → 完全な寿命切れ
• 「別のファイルとして開き直されている」 → FD 再利用による論理的事故の可能性

といった切り分けが可能です。

同様の情報は、/proc ファイルシステムからも取得できます。

ls -l /proc/1234/fd 

このディレクトリ内のシンボリックリンクは、FD 番号から実体（ファイル・ソケットなど）への対応を示しています。定期的にスナップショットを取ることで、「ある時点では FD 5 が file.log を指していたが、後の時点では別のファイルになっている」といった変化も観察できます。

---

3. 再現性のある「ミニマムな手順」を言語化する

EBADF を根本的に解決するには、「こういう操作をすると、ほぼ確実に EBADF が出る」という再現手順をテキスト化しておくことが有効です。例えば、次のような形です。

1. サービス A を起動する（systemd ユニット foo.service）
2. ログローテートを手動実行する（logrotate -f）
3. その直後に、サービス A のログに EBADF が出る

この手順と、strace / lsof / /proc から得られた事実を組み合わせることで、次のような仮説検証が可能になります。

• ログローテート後に、アプリケーションが古い FD を使い続けているのか？
• systemd の ExecReload や SIGHUP ハンドラの中で、FD の開き直しが正しく行われているか？
• 複数プロセス間で FD の所有権があいまいになっていないか？

ここまで来ると、単に「EBADF が出ている」という漠然とした状態から、

• どの FD が、
• どのシステムコールで、
• どのタイミングで EBADF を返しているか

を、事実ベースで把握できるようになります。これは、外部の専門家（例：株式会社情報工学研究所）に相談する際にも非常に重要な情報です。再現手順と最小限のトレースがあれば、原因特定や恒久対策の設計が格段に進めやすくなります。

次章では、こうして切り分けた情報を踏まえ、CentOS のサービス管理（systemd）とファイルディスクリプタ管理の関係を整理し、「再起動に頼らずに再設定・再接続で立て直す」ための設計の土台を作っていきます。

　

CentOSのサービス管理（systemd）とファイルディスクリプタの関係を整理する

CentOS 7 以降の多くの環境では、サービス起動とプロセス管理は systemd によって行われています。EBADF を本気でつぶしにいくなら、「アプリケーションコードの中だけ」を見ても不十分で、systemd とファイルディスクリプタの関係を理解しておく必要があります。

現場でよくある本音として、

「正直、ユニットファイルのオプションはテンプレをコピペしてるだけで、FD 周りはよく分かっていない」

という声があります。これは決して珍しい話ではなく、CentOS の導入時にベンダーや他社の設定をそのまま流用しているケースではむしろ一般的です。ただ、この「よく分からないものに触りたくない」感覚が、EBADF の伏線になることがあります。

---

1. systemd がサービスに渡すファイルディスクリプタ

systemd は、サービスプロセスを起動する際に、少なくとも次の FD を開いた状態で execve(2) します。

• 0：標準入力（通常は /dev/null か、別ユニットが渡したパイプ）
• 1：標準出力（journald へのパイプ、ログファイル、コンソールなど）
• 2：標準エラー出力（同上）

さらに、socket ユニットを組み合わせた「ソケットアクティベーション」を使っている場合、リッスンソケットが 3 以降の FD として事前に開かれ、環境変数（例：LISTEN_FDS）とともにサービスに渡されます。アプリケーション側は、この FD を「自分で socket() して bind() したもの」と同じように扱う設計にします。

ここでの重要ポイントは、「アプリケーションが意図していない FD が、プロセス起動時点ですでに開いている」という事実です。EBADF を避けるためには、これらの FD を不用意に close() しないだけでなく、どの FD が誰の所有物なのかを明確に切り分けて扱う必要があります。

---

2. ユニットファイルの設定と FD のライフサイクル

systemd のサービスユニットには、ログや FD に関係するいくつかの代表的な設定項目があります。

• StandardOutput= / StandardError=（journal, syslog, file など）
• LimitNOFILE=（プロセスが開ける FD の上限）
• ExecStart= / ExecReload= / ExecStop=（再設定時の挙動）
• Restart=（異常終了時の再起動ポリシー）

例えば、StandardOutput=file:/var/log/foo.log のように設定すると、systemd はログファイルを開き、その FD を標準出力としてサービスに渡します。この場合、アプリケーション側で同じファイルを別途開いてログを書き込む必要はありませんが、逆に言うと「systemd が所有しているログ FD を、アプリが勝手に閉じるべきではない」という制約が生まれます。

一方、LimitNOFILE はプロセスの FD 上限を制御するための設定です。本番環境だけこの値が高く（あるいは低く）設定されており、テスト環境と挙動が異なる、ということもあります。FD 上限に近づいた状態では、意図しない FD 再利用やエラーが発生しやすくなり、EBADF だけでなく EMFILE（Too many open files）と併発することもあります。

---

3. systemd 再読み込みと FD の再設定

設定変更やログローテート時に、systemd 経由でサービスを再読み込みする場合、例えば以下のようなコマンドが使われます。

systemctl reload foo.service 

このとき、ユニットファイル側で ExecReload= が設定されていれば、そのコマンドが実行されます。多くのデーモンや Web サーバーでは、このハンドラの中で設定ファイル読み込みやログファイルの開き直しを行いますが、その実装が不十分だと、

• 古い FD を閉じてしまったが、新しい FD の開き直しに失敗している
• 一部のワーカープロセスだけが新しい FD を参照し、残りが古い FD を使い続ける

といった状態になり得ます。結果として、一部のプロセスで EBADF が発生し、ログや接続の不自然な欠損として現れることがあります。

「reload したら一瞬だけ EBADF が出るけれど、すぐ落ち着くから気にしていない」という環境もありますが、それは裏側で FD のライフサイクルが綱渡りになっているサインかもしれません。

---

4. 再起動 vs 再設定の設計方針

systemd は Restart=on-failure などを指定することで、異常終了時に自動再起動を行えます。これは便利ですが、EBADF のような論理バグを「再起動でリセットする文化」を強化してしまう面もあります。

本記事で目指したいのは、

• 「致命的な状態なら安全に落とす」
• 「そうでない場合は、FD の開き直しなど再設定で立て直す」

という2段構えの設計です。そのためには、systemd ユニットとアプリケーションの両方で、再設定用のフック（ExecReload や SIGHUP ハンドラなど）を設計段階から組み込んでおく必要があります。

次章では、実際にログ・ソケット・パイプといった FD を「安全に開き直す」ための設計パターンを整理し、EBADF を「単なるエラー」から「自己修復のトリガー」に変えていく方法を考えていきます。

　

ログ・ソケット・パイプを安全に「開き直す」ための設計パターン

ここからは、具体的に「どのように FD を開き直せば EBADF を回避しつつ、サービスを落とさずに済ませられるか」という設計パターンを整理します。対象は主に次の3種類です。

• ログファイル
• ネットワークソケット
• パイプ・FIFO・UNIX ドメインソケット

どれも CentOS 上の常駐プロセスで多用されるリソースです。

---

1. ログファイルの開き直しパターン

ログローテート後に EBADF が出るパターンはよく知られています。典型的な対策としては、ログライブラリやアプリケーション内で「再オープン処理」を実装し、SIGUSR1 や SIGHUP を受け取ったタイミングで次のような手順を踏みます。

1. 現在のログファイルへの FD を 閉じずに、まず fflush() 等でバッファをフラッシュする
2. ローテート済みファイルとは別に、新しいログファイルを open() する
3. 新しい FD が取得できてから、必要に応じて古い FD を閉じる

ここで重要なのは、「新しい FD が確保できるまでは、古い FD を手放さない」という順番です。万一 open() に失敗した場合でも、古い FD でログを継続できる余地を残せます。

また、マルチスレッド環境では、ログへの書き込みを1か所に集約し、他のスレッドはキュー経由でログメッセージを渡す設計がよく用いられます。このような「ログワーカースレッド方式」にしておくと、FD の開き直し処理もそのスレッド内に閉じ込めることができ、他のスレッドが古い FD を握り続けるリスクを減らせます。

---

2. ネットワークソケットの再接続パターン

外部サービスへの TCP 接続などで EBADF やその他の I/O エラーが発生した場合、一般的には次のような処理パターンを取ります。

• エラー発生時に、その FD を閉じる
• 一定のバックオフ（再試行間隔）を置いて、新しいソケットを socket() から作り直す
• 再接続が成功したら、アプリケーションの状態を「接続済み」に戻す

ここでの注意点は、「エラーが出たらとにかく close」だけでは十分でないということです。前章までで見たとおり、FD 番号自体は再利用されるため、「エラーが出た FD 番号」をローカル変数やグローバルに残したままにすると、後続処理で誤って使われる可能性があります。

そのため、再接続ロジックでは、

• FD 番号を保持する変数を「無効値」（例：-1）にクリアする
• FD をフィールドとして持つ構造体やクラスの場合、そのオブジェクト自体を再生成する

といった「論理的な破棄」も合わせて行うことが重要です。単に close() するだけでは、コード上の状態モデルが更新されず、EBADF の再発を招きます。

---

3. パイプ・FIFO・UNIX ドメインソケットの再生成

プロセス間通信で使われるパイプ・FIFO・UNIX ドメインソケットは、ログファイルや TCP ソケットに比べて「どのプロセスがどの FD を責任を持って閉じるか」が曖昧になりやすいリソースです。

例えば、systemd の socket ユニットで UNIX ドメインソケットを作成し、複数のワーカープロセスが接続する構成を考えてみます。この場合、ソケットファイルの生成・削除は systemd が行い、ワーカープロセスはクライアントとして接続します。

この構成で EBADF が生じた場合、

• systemd 側のソケットユニットが適切に動いているか
• ワーカープロセス側が古い接続を適切に閉じているか

を切り分ける必要があります。ワーカープロセス側では、TCP と同様に、

• エラー発生時に接続 FD を閉じ、変数を無効値にする
• 一定のポリシーに基づき、再接続を試みる

といったパターンを取るのが一般的です。重要なのは、「どのプロセスがソケットファイルそのものを作成・削除するか」と、「どのプロセスが接続 FD を管理するか」を混同しないことです。

---

4. 「開き直し」を前提にしたアーキテクチャ

ここまでのパターンをまとめると、EBADF を怖がらずに扱うためには、

• ログ・ソケット・パイプなどを「開きっぱなしの前提」で設計しない
• 一定のトリガー（シグナルや設定変更、エラーなど）で FD を開き直す前提で設計する

ことがポイントになります。現場の本音としては、

「正直、開き直し前提の設計にするとコード量も増えるし、テストも大変になる」

という感覚もあると思います。これは確かに一面の真実ですが、FD を開き直すことを前提にしておくと、

• ログローテートや構成変更に柔軟に対応できる
• 障害発生時に「FD を開き直して立て直す」という選択肢を持てる

という長期的なメリットがあります。次章では、こうした設計を支える「運用側の工夫」として、ログローテートや設定変更時に EBADF を出さないための運用設計を具体的に見ていきます。

　

ログローテートや設定変更時にEBADFを出さないための運用設計

ここまでで、FD を安全に開き直すための設計パターンを見てきました。しかし、コードの作り込みだけではカバーしきれないのが「運用の現実」です。ログローテートや設定変更は、現場の事情（監査要件、容量制限、メンテナンス時間など）に強く縛られるため、運用設計がアプリケーションと噛み合っていないと、どうしても EBADF を含む I/O エラーが出やすくなります。

ここでは、CentOS 環境でよく使われるログローテート・設定変更のパターンと、それに対応した運用設計の考え方を整理します。

---

1. logrotate とデーモン側の連携

CentOS では /etc/logrotate.d/ 以下の設定ファイルを通じて、ログローテートが定期実行される構成が一般的です。代表的なオプションとしては、

• copytruncate：元ファイルをコピーしたあと、元ファイルを空にする
• create：ローテート後に空の新ファイルを生成する
• postrotate ... endscript：ローテート後に任意のコマンドを実行する

アプリケーション側でログの開き直しを行う場合は、postrotate ブロックでデーモンにシグナルを送る構成がよく用いられます。

/var/log/foo/app.log { daily rotate 7 missingok notifempty compress delaycompress create 0640 appuser appgroup postrotate /bin/systemctl kill -s HUP foo.service || true endscript } 

この場合、

• logrotate がファイルをローテートし、新しいファイルを作成する
• その後、SIGHUP が foo.service のメインプロセスに送られる
• デーモン側は、SIGHUP をトリガーにログファイルの開き直しを行う

という流れになります。ここで大事なのは、「どのタイミングで FD を閉じ、新たに開くか」の責任を明確にアプリケーション側に寄せることです。logrotate の copytruncate を使って無理やりファイル内容だけをすり替えると、アプリケーション側の FD 管理と噛み合わず、結果として EBADF やログ欠損の要因になることがあります。

---

2. 設定変更の手順を「人間の作業手順」として設計する

設定変更時に EBADF が出るケースでは、「やり方が毎回バラバラ」という運用も見受けられます。たとえば、

• ある担当者は systemctl reload を使う
• 別の担当者は systemctl restart を使う
• 夜間担当は kill -HUP を直接打つ

といった状況です。このような運用では、アプリケーション側でいくら丁寧に再設定ロジックを書いても、「たまたま想定外の操作が行われたタイミングで EBADF」が発生します。

そこで重要になるのが、「設定変更の標準手順書」を具体的に文章に落とすことです。例えば、

1. 設定ファイルを変更する
2. 構文チェックを行う（例：専用コマンドやテスト環境）
3. systemctl reload foo.service を実行する
4. ジャーナルとアプリケーションログの両方を確認し、エラーがないことを確認する

といった形で、「何を」「どの順番で」行うかを決めておくことで、EBADF を含む I/O エラーの発生タイミングを限定できます。これは、後から原因調査をする際にも非常に役立ちます。

---

3. 監視とアラート設計：EBADF を単なるノイズにしない

EBADF を本気でつぶしにいくなら、「ログに出たら grep でなんとなく眺める」という運用から一歩進めて、監視設計の中に取り込むことも効果的です。例えば、

• journald やログ収集基盤で "Bad file descriptor" を集計する
• 単発の EBADF は情報レベル、一定期間に複数回出たら警告レベル、連続発生したら重要アラート…といったしきい値を決める

といった方法です。ここでも、現場の本音としては、

「正直、アラートを増やすと運用が回らなくなるんじゃないか…」

という懸念があると思います。そのため、最初は「ダッシュボードで傾向を見るだけ」「週次レポートで件数を確認するだけ」といった軽い導入から始め、徐々にしきい値や運用ルールを整えていく方法が現実的です。

---

4. 運用設計とコード設計の「すり合わせ」をどこでやるか

ここまで見てきたように、EBADF を抑え込むには、

• アプリケーションコード側の設計
• systemd ユニット定義
• logrotate などの補助ツール設定
• 現場の運用手順

が「ひとつのストーリー」としてつながっている必要があります。どこか1か所だけを最適化しても、他の部分との整合性が取れていなければ、結局 EBADF は再発します。

とはいえ、現場では、アプリケーション開発チーム・インフラチーム・運用チームが分かれていることも多く、「誰が全体を見て設計を裁くのか」が曖昧になりがちです。ここがまさに、外部の専門家（例：株式会社情報工学研究所）が価値を出せるポイントです。

第三者として全体の構成と運用を俯瞰し、

• どこまでをアプリ改修でカバーし、
• どこからを運用設計の見直しでカバーするか

を整理することで、「再起動でなかったことにする」文化から一歩進んだ設計・運用へと舵を切ることができます。

次章では、こうした運用と設計を前提に、「落とさず立て直す」ための再設定ハンドラやフェイルセーフの具体的な考え方を整理し、EBADF をトリガーにした自己修復の道筋を描いていきます。

　

「落とさず立て直す」ための再設定ハンドラとフェイルセーフの書き方

ここからは、「EBADF が出たら即サービス再起動」ではなく、できる限りプロセスを落とさずに立て直すための設計を具体的に考えます。現場の本音としては、

「夜中に落ちるくらいなら、多少のログ欠損は飲み込んででも動き続けてほしい」

というニーズが強くあります。一方で、無理に動かし続けると、データ破壊や整合性崩壊につながるケースもあります。そこで重要になるのが、再設定ハンドラとフェイルセーフの境界線をどこに引くかです。

1. 「再設定で済ませてよい」ケースと「安全に落とすべき」ケース

まずは、EBADF が出たときの扱い方を大きく2つに分けて考えます。

• 再設定で回復を試みるケース
  例：ログ出力用 FD、外部サービスへの一時的な TCP 接続、キャッシュ用途の補助プロセスとの通信など。
• 安全のためにプロセスを終了すべきケース
  例：トランザクションログ、ジャーナル、ストレージへの書き込み FD など、データの一貫性に直接関わる FD。

EBADF が「単なるログの書き損ね」なのか、「コアとなるデータ書き込みの破綻なのか」を区別するために、コード上で FD の役割を明示的に分類しておくことが重要です。例えば、ログ FD には fd_class = LOG、重要なストレージ FD には fd_class = STORAGE_CRITICAL といったメタデータを持たせる設計です。

2. 再設定ハンドラの基本パターン

EBADF を受け取った関数で、すぐに exit() に行くのではなく、次のようなステップで「立て直し」を試みるパターンが考えられます。

1. エラー発生箇所で、対象 FD の役割（ログ／補助的なソケットなど）を判定する
2. 再設定対象であれば、専用の「リカバリハンドラ」を呼び出す
3. リカバリハンドラ内で FD を閉じ、関連する状態を「未初期化」に戻す
4. 必要に応じてバックオフを挟みながら、再初期化関数を呼ぶ
5. 再初期化に成功したら、処理を継続する／失敗が続く場合は上位にエラーを伝搬する

疑似コードで表現すると、次のようなイメージです。

ssize_t safe_write(struct fd_wrapper *w, const void *buf, size_t len) { ssize_t n = write(w->fd, buf, len); if (n < 0 && errno == EBADF) { if (w->class == FD_CLASS_LOG) { if (try_reopen_log(w) == 0) { return write(w->fd, buf, len); /* 再試行 */ } else { /* ログだけ諦めて処理継続、などポリシーを決める */ return 0; } } else if (w->class == FD_CLASS_STORAGE_CRITICAL) { /* データ整合性に関わる FD は、プロセス終了など強い対応 */ abort(); } } return n; } 

ここで重要なのは、「どのクラスの FD に対してどこまでリカバリを試みるか」を明文化しておくことです。

3. フェイルセーフとしての「切り離し」と「縮退運転」

再設定で立て直しきれない場合でも、「いきなり全体を落とす」のではなく、部分的に機能を停止して縮退運転に入る選択肢もあります。例えば、

• 集計・分析系のログ出力だけを停止し、主要機能は継続する
• 一部の補助サービスへの接続を諦めて、コア機能だけを提供する

といった形です。もちろん、こうした縮退運転を行う場合は、監視やダッシュボードで「現在は縮退中」であることが分かるようにしておく必要があります。これもまた、アプリケーション設計だけでなく、運用設計とのすり合わせが必要な部分です。

4. チームとしての合意形成

再設定ハンドラとフェイルセーフの設計は、個人の美学だけで決めてしまうと危険です。「このエラーが出たらどう振る舞うか」は、ビジネス要件・SLA・法令・監査要件などとも密接に関係します。

そのため、

• どの種類の FD で EBADF が出たら、どのレベルの対応を取るか
• どの範囲までが再設定で、それ以降はプロセスを止めるか

といったルールを、チームとしてドキュメントに落とすことが重要です。この整理ができていれば、外部の専門家（株式会社情報工学研究所など）に相談するときも、「どこまでを社内ポリシーとして決めておきたいか」「どこからを技術的に詰めてほしいか」を明確に伝えやすくなります。

次章では、こうした「落とさず立て直す」設計を前提に、再起動前提の運用から一歩進み、EBADF を自己修復のトリガーとして活用していく考え方を整理します。

　

再起動前提の運用から「EBADFをトリガーにした自己修復」への考え方

多くの現場では、長年の経験から「定期再起動しておけばなんとなく安定する」という運用が根付いています。これはある種の現実解でもありますが、システムの複雑さや可用性要求が上がるにつれて、再起動前提の運用には限界が見え始めます。

ここでは、EBADF を「障害の最終形」ではなく、「自己修復のトリガー」として扱う考え方を整理します。

1. 「ゼロ障害」幻想からの距離の取り方

まず押さえておきたいのは、どれだけ丁寧に設計・実装しても、

• 予期しないトラフィックパターン
• 外部サービスの仕様変更
• ライブラリのバグ

などにより、EBADF を含む I/O エラーが完全にゼロになる保証はない、という事実です。「ゼロ障害」を目標にしてしまうと、現場は「エラーが出た＝失敗」というプレッシャーを感じ、ログを抑制したり、障害を隠したりする方向に傾きかねません。

むしろ、

「エラーは一定の確率で起きるもの。そのときにどう検知し、どう収束させるかが設計の勝負どころ」

と捉える方が、現実的です。

2. EBADF を検知する仕組みをアプリ側に組み込む

EBADF を自己修復のトリガーにするには、「どの層で EBADF を検知するか」を決める必要があります。具体的には、

• ライブラリ層でのリトライに任せる
• アプリケーション層で EBADF を検知し、専用ハンドラに渡す
• OS レイヤのログだけに頼る（推奨されない）

といった選択肢があります。一般的には、アプリケーション層で EBADF を検知し、意味のあるログとともにリカバリハンドラに渡すパターンが扱いやすいことが多いです。

例えば、先ほどの safe_write() のようなラッパを経由させれば、「いつ・どの FD で EBADF が出たか」を一元的に記録できます。この情報は、自己修復のロジックを実装する際にも、外部の専門家に解析を依頼する際にも役立ちます。

3. 自己修復の上限と「観測可能性」

自己修復を設計する際に忘れてはいけないのが、「どこまで自動で頑張り、どこからは人間に知らせるか」という上限の設定です。例えば、

• 一定期間内に EBADF が N 回を超えたら、自己修復を止めてアラートを上げる
• 自己修復の結果もログに残し、「どれだけリカバリが走ったか」を後から確認できるようにする

といったルールを設けることで、「自動で立ち直ったけれど、実は裏で FD 周りのトラブルが多発していた」といった状態を避けられます。

この「観測可能性」を確保しておかないと、自己修復は「障害を隠す仕組み」に見えてしまい、チームの信頼を失います。逆に言えば、自己修復の動きがきちんと見えるように設計しておけば、

「この3か月、EBADF は月に数回発生しているが、すべて自動リカバリできている」

といった事実ベースの対話ができるようになります。

4. 外部専門家の活用ポイント

自己修復の枠組みを作るところまでは社内で進められても、

• ファイルディスクリプタ管理の細部
• systemd・logrotate・アプリコードの組み合わせ
• 高可用性構成やクラスタ化との整合性

などは、どうしても判断が難しくなることがあります。このような局面では、Linux サーバー障害・データ復旧・ログ解析を専門としている外部の技術者に相談することで、

• 「いまの自己修復設計が、どの程度妥当なのか」
• 「どの部分に中長期的なリスクが残っているのか」

を客観的に評価してもらうことができます。株式会社情報工学研究所のように、ファイルシステムレベルの障害調査やログフォレンジックも扱っている事業者であれば、EBADF をきっかけにした「より広いリスク評価」まで含めて相談することも可能です。

次の章では、ここまでの内容を踏まえ、「EBADF を怖がらないチーム」になるために今日から見直せるチェックポイントを整理しつつ、一般論の限界と、個別案件では専門家に相談すべき理由をまとめます。

　

EBADFを怖がらないチームになるために今日から見直せるチェックリスト

最後に、ここまでの内容を現場で使えるチェックリストという形に整理します。目的は、「EBADF が出たら終わり」ではなく、「EBADF をきっかけに設計と運用を一歩前進させる」チームになることです。

1. 設計とコードに関するチェック

• ファイルディスクリプタを扱う部分（open/close、ソケット接続など）が、ラッパ関数やクラスで抽象化されているか
• FD ごとに「役割（ログ／ストレージ／補助通信など）」を識別できる情報を持っているか
• 二重 close を防ぐために、close() 後は FD を -1 などの無効値にクリアしているか
• マルチスレッド・マルチプロセス環境で、どのコンテキストがどの FD を所有しているかが明文化されているか
• EBADF 発生時に呼び出す「再設定ハンドラ」が用意されているか

2. systemd・logrotate・運用に関するチェック

• systemd ユニットファイルの StandardOutput / StandardError の設定を把握しているか
• LimitNOFILE の値を把握し、テスト環境と本番環境で大きな差がないか確認しているか
• logrotate の設定が、アプリケーション側のログローテート設計（シグナルハンドラなど）と整合しているか
• 設定変更や再読み込みの標準手順が文書化されており、担当者によってバラバラな操作をしていないか
• EBADF を含む I/O エラーの発生状況を、監視やレポートで定期的に確認しているか

3. 心理的・組織的なチェック

• 「エラーが出ること自体」を過度に恐れず、「どう扱うか」に意識を向けられているか
• 障害報告の文化が「責任追及」ではなく、「再発防止と改善」の方向を向いているか
• アプリ開発・インフラ・運用の間で、FD やログに関する情報共有が行われているか
• 「再起動で一時的に直った」ケースでも、後日きちんと原因分析の場を持つ習慣があるか

4. 一般論の限界と、専門家に相談すべきポイント

ここまでの記事は、Linux / CentOS 上で一般的に通用する範囲の技術的な一般論に基づいています。しかし、実際の案件では、

• ストレージ構成（RAID / LVM / iSCSI / 分散ストレージなど）
• クラスタ構成やフェイルオーバーの仕組み
• 医療・金融・公共インフラなど業種ごとの法令・監査要件
• 既存ベンダーとの契約条件や保守範囲

といった要素が絡み合い、「教科書どおりのベストプラクティス」をそのまま当てはめられない場面が少なくありません。

例えば、

• EBADF が出たタイミングで一部ログが欠損しているが、監査上どこまで説明が必要か
• FD 周りの不具合が、今後のデータ復旧や証拠保全にどのような影響を与えるか
• クラウドやオンプレミスをまたいだ構成で、どのレイヤまでを社内で責任を持てるか

といった論点は、技術だけでなく、契約・ガバナンス・事業継続計画（BCP）とも関係します。ここは、記事レベルの一般論だけでは判断しきれない部分です。

5. 具体的な次の一歩：株式会社情報工学研究所への相談

もし、

• CentOS やその他 Linux サーバーで EBADF が散発しており、根本原因を整理したい
• ログ欠損やストレージ障害も含めて、データ復旧や将来のトラブル時のリスクを評価したい
• 医療機関・企業・官公庁向けシステムで、FD 周りを含むインフラ設計と BCP を見直したい

といった課題をお持ちであれば、株式会社情報工学研究所のような、データ復旧・サーバ障害解析の専門事業者に一度ご相談いただくのが現実的です。

本記事で整理したような「strace ログ」「lsof 出力」「再現手順メモ」などを併せてご提供いただければ、単に「EBADF を消す」だけでなく、

• 今後起こり得るリスクの洗い出し
• 設計・運用・監視のどこをどう変えると安定性が上がるか

といった観点まで含めて、より具体的な提案につなげることができます。

EBADF を「怖い謎のエラー」として避けるのではなく、「設計と運用を一段上げるためのきっかけ」として捉え直す。そのプロセスを、必要に応じて外部の専門家と一緒に進めていただければと思います。

　

補遺：主要なプログラム言語ごとのEBADF・FD周りの注意点

最後に、現在よく使われている代表的なプログラム言語ごとに、EBADF やファイルディスクリプタ取り扱いの観点で注意しておきたいポイントを簡潔に整理します。ここで挙げる内容は一般的な傾向であり、実際の挙動は各言語ランタイムやバージョン、利用しているフレームワークに依存します。

C / C++

• システムコールや open()/close() を直接扱うことが多く、二重 close・エラーチェック漏れが EBADF の主因になりやすい。
• FILE*（標準ライブラリのストリーム）と生 FD（int）を混在させる場合、それぞれのライフサイクル管理を分けて考える必要がある。
• 例外機構がない C では、戻り値と errno を毎回確認する実装スタイルが重要になる。

Java / JVM 言語

• 通常は InputStream / OutputStream、Channel 等の抽象化を通じて FD を扱うため、アプリコードで EBADF を直接見ることは多くない。
• ただし、close() の呼び忘れや、明示的に close() したオブジェクトを再利用すると、内部的に EBADF が発生し、例外として表面化することがある。
• スレッドや Executor サービス内での I/O 処理では、例外が握りつぶされないようにロギングとハンドリングを設計する必要がある。

Python

• with 文（コンテキストマネージャ）を使うことで FD の自動クローズが行われるが、手動で close() を呼ぶコードと混在するとライフサイクルが分かりにくくなる。
• 標準ライブラリやサードパーティライブラリ内部で FD を開閉しているケースが多く、「ちょっとしたラッパ」を独自に挟んだ結果、二重 close の原因になることがある。
• マルチプロセス（multiprocessing）や uWSGI/Gunicorn などと組み合わせる場合、fork() 後の FD 共有を意識した設計が必要。

Ruby

• IO オブジェクトと FD の対応は抽象化されているが、IO.for_fd などを使って直接 FD を扱う場合は C と同様の注意が必要。
• Web アプリケーションフレームワーク（Rails 等）では、アプリ本体よりもアプリサーバ（Puma, Unicorn など）の FD 管理が EBADF の焦点になることが多い。

Go

• ネットワーク接続やファイル I/O は抽象化されているが、net.Listener や os.File を跨いだゴルーチン間の共有でライフサイクルが複雑化することがある。
• defer による Close() で「とりあえず閉じておく」パターンを多用すると、予期しないタイミングでの close が発生し、別のゴルーチンから EBADF 相当のエラーが返る場合がある。

Rust

• 所有権・借用の仕組みにより、FD ライフサイクルは比較的安全に管理されるが、std::os::unix::io::RawFd を直接扱うコードでは C と同様の注意が必要。
• unsafe ブロック内でのシステムコール呼び出しは、エラーチェックと Result のハンドリングを徹底する必要がある。

Node.js（JavaScript ランタイム）

• 非同期 I/O とコールバック／Promise を組み合わせるため、エラーの伝搬経路が長くなりがちで、EBADF 相当のエラーがどこで発生したか追いにくい。
• HTTP サーバ・ストリーム・ファイル I/O を組み合わせた処理では、「どのタイミングで .end() / .destroy() したか」をトレースできるようにロギングすることが重要。

PHP

• 典型的な Web 実行環境（リクエストごとにプロセス／ワーカーが分離される）では、リクエスト内で開いた FD はリクエスト終了とともに破棄されるため、長寿命 FD に起因する EBADF は出にくい。
• 常駐プロセス型（常駐ワーカーや CLI デーモン）として PHP を使う場合は、他言語と同様に FD ライフサイクル管理が必要になる。

まとめ：言語が違っても OS のルールは同じ

どの言語でも、最終的には Linux カーネルの FD 管理ルールの上で動いています。抽象化のレイヤは違っても、

• 「開いた FD はどこで、誰が閉じるのか」
• 「閉じたあとに参照していないか」
• 「マルチスレッド・マルチプロセスで所有権が曖昧になっていないか」

という問いは共通です。もし複数言語が混在するシステム（例：C で書かれたデーモン＋Java の業務アプリ＋Python の運用スクリプト）が同じサーバーで動いている場合は、言語ごとの習慣の違いが FD 周りのバグを生みやすくします。

こうした混在環境では、単一の言語に精通したエンジニアだけで判断するのではなく、OS レベル・ファイルシステムレベルを含めて俯瞰できる専門家と一緒に設計・レビューを行うことが、安全側に倒すうえで有効です。株式会社情報工学研究所では、データ復旧やサーバ障害対応の現場経験を踏まえて、「どのレイヤから調査・改善に着手するのがもっとも合理的か」といった観点での相談も可能です。

EBADF や FD 周りの問題が気になっているのであれば、まずは小さな範囲（1サービスや1システム）からでも構いません。具体的なログや構成情報をベースに、一緒に整理を進めていくことで、再起動頼みではない安定運用への一歩を踏み出せるはずです。