Linux EINTR (4) 診断：シグナル割り込みによるエラーの検出と対処編

【注意】 本記事は一般的な技術情報の整理であり、実環境の障害対応は状況（カーネル/ライブラリ/設定/負荷/運用制約）で結論が変わります。判断に迷う場合や影響が大きい場合は、株式会社情報工学研究所のような専門事業者へ相談してください。

　

第1章：深夜の `read()` が突然 -1——「再現しないのに落ちる」現場のモヤモヤ

ログに残るのは、ただの一行――Interrupted system call。あるいは errno=4（EINTR）。それだけなのに、現場の体感はもっと重いはずです。「昨日まで動いていたのに」「負荷が高いわけでもないのに」「テスト環境で再現しないのに」──この手の不規則さは、説明コストも心理コストも高いからです。

特にレガシーなシステムでは、I/Oの戻り値を“想定外”として扱っている箇所が残りがちです。たとえば、ブロッキングI/Oが -1 を返すのは「致命」だ、という古い前提のまま実装されていると、EINTRは実害になります。ここで必要なのは、パニックではなくノイズカットとダメージコントロールです。つまり「割り込みが起きる前提」で、検出し、切り分け、影響を最小化する設計と運用に落とすことです。

---

現場で起きるEINTRの“見え方”

EINTRは、システムコールが完了する前にシグナルを受け、処理が中断されたことを意味します。典型的には、次のような場面で「突然」起きます。

• ソケット待ち（accept() / recv()）が中断される

• ファイルI/O（read() / write()）が中断される

• 多重化待ち（select() / poll() / epoll_wait()）が中断される

• 子プロセス待ち（wait() / waitpid()）が中断される

ここで厄介なのは、“割り込み”は外部要因に見えることです。プロセス自身がタイマーを使っていたり、別スレッドがシグナルハンドラを仕込んでいたり、監視の都合で親プロセスからシグナルが飛んできたりします。コードを追っても「自分が送っていない」ように見えてしまい、議論が過熱しやすい領域です。

---

「説明が難しい」の正体：再現性ではなく観測性の問題

多くのチームで起きるのは、「原因究明が難しい」というより「観測が足りない」状態です。EINTR自体は仕様の範囲内ですが、どのシグナルが、どのシステムコールを、どのタイミングで割り込んだかが見えないと、対策が“勘”になります。

まずは、現場の説明資料として最低限そろえるべき情報を決めましょう。次の表は、障害対応で揉めやすいポイントを“場を整える”ためのチェックです。

観測したいもの	例	目的
どのシステムコールで起きたか	read/accept/epoll_wait/waitpid	再試行の可否と実装箇所を絞る
どのシグナルか	SIGCHLD/SIGALRM/SIGTERM など	送信元（自分/親/監視/端末）を推定する
頻度と時刻帯	夜間・ローテ中・バッチ時間	運用イベント（監視/ローテ/ジョブ）との相関を見る
ハンドラ設定	SA_RESTART の有無	自動再開される/されないの境界を把握する

---

本記事のゴール：EINTRを“運用のブレーキ”にしない

このブログの狙いは、EINTRを「不気味な偶発エラー」から「扱える仕様」へ落とし込むことです。具体的には、

• 検出：EINTRが起きた事実をログで説明できる

• 診断：どのシグナル/どの箇所かを切り分けられる

• 対処：安全に再試行する/しないを判断できる

• 再発防止：運用・設計で“割り込み耐性”を上げる

この流れができると、障害対応のたびに議論が過熱してチームの速度が落ちる、という事態に歯止めがかかります。

　

第2章：EINTR(4) とは何か——「エラー」ではなく“シグナルで割り込まれた”という事実

EINTR（errno=4）は、Linuxで「システムコールがシグナルにより中断された」ことを表す代表的なエラーです。ポイントは、EINTRが示すのは“失敗原因の多様さ”ではなく、「割り込みが起きた」という単純な事実だという点です。だからこそ、対処方針は「再実行してよいか」「どこで再実行すべきか」に集約されます。

---

POSIXとLinuxの基本：シグナルが割り込むと何が起きる？

ブロッキング中のシステムコールは、シグナルを受けると中断され、-1 が返り、errnoにEINTRがセットされることがあります。ここで重要なのは、“必ずEINTRになる”わけではないことです。シグナルハンドラの設定（特に SA_RESTART）や、対象システムコールの種類によっては、自動的に再開され、呼び出し側がEINTRを見ないケースもあります。

この差が、現場で「ある時だけ起きる」「ある環境だけ起きる」という見え方を生みます。つまりEINTRは、アプリの実装だけでなく、ライブラリや設定、運用の“周辺条件”によって顔を出したり隠れたりします。

---

「再試行で片付く」ものと「再試行が危険」なもの

エンジニアがまず押さえるべきは、EINTRを見たときの基本姿勢です。多くの待ち系（accept、poll、epoll_waitなど）は、EINTRなら再試行してよい場面が多い一方で、I/Oは「部分完了」や「副作用」を伴う可能性があります。

分類	例	EINTR時の基本
待ち（副作用が小さい）	accept / poll / epoll_wait	原則リトライ（ただし終了要求と区別）
I/O（副作用があり得る）	read / write	戻り値と意味を確認し、安易に二重実行しない
待ち＋意味が重要	wait / waitpid	子プロセス状態との整合を意識して扱う

「じゃあ全部リトライすればいいじゃん」と言いたくなるのですが、ここでやってはいけないのは、終了要求（SIGTERMなど）まで無視して永久リトライに入ることです。EINTR対策は、障害の抑え込みであって、プロセスの生存を最優先する話ではありません。“落ちるべきときに落ちる”制御（シャットダウンやキャンセル）もセットで設計する必要があります。

---

最小の実装原則：EINTRを“仕様として扱う”

実装側で最低限やるべきことは、次の2点です。

1. EINTRを“想定外の失敗”として扱わない（例：即fatalログで終了しない）

2. 「リトライするなら、どこで、どの条件で止めるか」を明文化する

ここまでができると、EINTRは「不具合」ではなく、「割り込みの存在を示す観測点」になります。次章からは、その割り込みがどこから来るのかを、運用現実と結びつけて整理します。

　

第3章：なぜ今も起きる？——タイマー、子プロセス、端末、監視、そしてSRE運用の副作用

現代のLinux運用では、プロセスが“静かに放置される”ことはほぼありません。監視、デプロイ、ログローテーション、ジョブ制御、コンテナのライフサイクル――これらは利便性と安全性を上げる一方で、シグナルという形でアプリに介入します。その介入がブロッキングI/Oと重なった瞬間に、EINTRが見えるのは自然な結果です。

---

よくあるシグナルの発生源（現場で説明しやすい順）

まずは「どのシグナルが、どんな運用イベントと結びつきやすいか」を押さえると、関係者の認識が揃い、議論の温度を下げやすくなります。

• SIGCHLD：子プロセスの終了/停止。外部コマンドを叩く実装、ワーカー起動、バッチ連携があると頻出。

• SIGALRM：タイマー。古い実装や一部ライブラリで、タイムアウト実装として使われることがある。

• SIGTERM：終了要求。systemd、Kubernetes、デプロイ、スケールイン、手動停止など、運用上もっとも重要。

• SIGINT：端末からの割り込み（Ctrl+C）。運用手順や手動オペの場面で発生。

• SIGHUP：設定再読み込みや端末切断。デーモンの再読み込み設計やTTY要因で出る。

ここでのポイントは、EINTRの犯人探しを“個人の責任”に寄せないことです。多くの場合、原因は仕組みの相互作用で、誰かのミスではありません。だからこそ、対策は「誰が悪いか」ではなく、「どの境界で割り込みを扱うか」という堤防を築く話になります。

---

レガシーが抱えやすい構造：割り込みとI/Oが混ざる境界

既存システムが簡単に止められない現場では、次のような構造が残っていることがあります。

• シグナルハンドラの中で状態を更新し、メインループがそれを見て分岐する

• 外部コマンド実行（fork/exec）とI/O待ちが同一スレッドに混在している

• タイムアウト実装がSIGALRM依存で、I/O待ちと衝突する

• 終了シーケンスが曖昧で、SIGTERMを受けても“どこで止めるか”が決まっていない

これらは「当時の合理性」があって作られたことが多く、単純に良し悪しで片づけられません。ただ、運用が高度化した今、割り込みが増える環境に置かれると、EINTRが“露出”してきます。言い換えると、EINTRは仕様外ではなく、環境変化のサインになり得ます。

---

“現場の本音”を否定しない：運用が増えるのはつらい

「また新しい観測？」「また例外処理？」「どうせ運用が増えるだけでは？」――そう思うのは自然です。EINTR対策で大事なのは、対策を増やすこと自体が目的化しないことです。EINTRをきっかけに、障害対応が長引く、説明が難しい、復旧判断が遅れる、という状況をクールダウンさせるのが本筋です。

次章では、ここまでの“なぜ起きる”を「どう観測して診断するか」に落とします。勘と経験に寄らず、再現性がなくても前に進める手順を整理します。

　

第4章：まずは観測から——strace / perf / audit で「割り込み」をログに残す

EINTR対策で最初にやるべきは、実装の修正よりも観測の整備です。なぜなら、EINTRは「起きること自体」が問題なのではなく、起きたときに説明できないことが問題になりやすいからです。現場で揉めるのは、対策の正しさより「誰が何を見て判断したのか」が共有できない時です。まず“場を整える”ために、EINTRが見えた瞬間に残す情報を決めます。

---

最低限のログ要件：EINTRを「現象」から「手掛かり」に変える

アプリのログに残すべき最小セットは、次の4点です。これが揃うと、原因追及が責任論に傾きにくくなり、対処の議論に集中できます。

• どの操作で（read/accept/epoll_wait/waitpid など）

• どのFD/対象で（ソケット/ファイル/子プロセスIDなど）

• どのタイミングで（時刻、スレッド/リクエストID、直前のイベント）

• どう扱ったか（リトライした/終了に寄せた/別エラー扱いにした）

「シグナル番号まで必須？」と思うかもしれませんが、運用の切り分けでは非常に効きます。SIGCHLDなら子プロセス連携、SIGTERMならデプロイや停止、SIGALRMならタイムアウト実装――といった具合に、関係者の持ち場（アプリ/基盤/運用）に自然に割り振れます。

---

strace：最短で“割り込みの瞬間”を押さえる

ユーザー空間の観測で最も手軽なのが strace です。EINTRが起きたシステムコールと、戻り値、errnoが見えます。さらに、シグナル受信（--- SIGxxx ---）が出るため、「どのシグナルが割り込ませたか」まで辿れます。

ここで重要なのは、straceを“常時”回すことではなく、障害時に最短で取れる形を準備することです。たとえば運用手順として、プロセスIDの特定→限定時間だけアタッチ→ログ保全、という形にしておけば、運用負荷を増やしません。目的は、障害対応を収束させる材料を素早く揃えることです。

---

perf/audit：原因が「シグナルの送信元」側にあるとき

アプリがEINTRを受けたとしても、シグナルを送った側が別プロセス（監視、親プロセス、ジョブ制御）であることは珍しくありません。その場合、アプリ内ログだけでは“外”が見えません。ここで候補になるのが、監査ログ（audit）や、プロセス周りのイベント追跡です。

運用上は、次のような整理が役立ちます。

観測手段	強み	向いている状況
アプリログ	実装の意図と紐づく	EINTRの扱い（リトライ/終了）を説明したい
strace	システムコールとシグナルが見える	どの呼び出しが割り込まれたかを即断したい
audit/運用ログ	送信元や運用イベントの痕跡が残る	外部要因（停止/再起動/監視）との相関を取りたい

---

観測の落とし穴：ログの出し方で“二次障害”を作らない

観測を増やすときに注意したいのは、ログの過剰出力でディスクI/OやCPUを押し上げ、別の障害の引き金になることです。EINTRの診断は、広く薄くではなく、必要な時に必要な粒度でが基本です。常時フルトレースではなく、一定条件（連続発生、特定の重要操作、SLAに影響する経路）でのみ詳細を出す設計が現実的です。

ここまでで「観測の準備」が整いました。次は、再現性がなくても前へ進めるために、あえて“狙って”EINTRを起こす方法を整理します。

　

第5章：再現性を作る伏線——SIGALRM・SIGCHLD・SIGINT で“狙って”EINTRを起こす

「本番だけで起きる」「テストでは再現しない」――この状況が長引くと、対策の議論が空転しやすくなります。ここでやりたいのは、原因を断定することではなく、EINTRを扱うコード経路が正しいかを検証できる状態を作ることです。つまり、EINTRを“再現する”のではなく、EINTRを受けたときの振る舞いを“検証する”ことに焦点を移します。

---

狙い：EINTRを“起こす”のではなく“受け止め方”をテストする

重要なのは、EINTRが起きる条件を完全に模倣することではありません。EINTRが返るシステムコールを用意し、そこにシグナルを当てて割り込みを発生させ、アプリが

• リトライすべきところでリトライする

• 終了すべきところで終了に寄せる

• ログが必要十分に残る

という“設計どおり”の動きをするかを確認します。これができれば、再現性問題は被害最小化できます。

---

代表的なシグナルとテストの狙い

実運用で出やすいシグナルを、テスト観点に落とすと整理しやすくなります。

シグナル	現場の発生源	テストで確認したいこと
SIGTERM	停止、デプロイ、スケールイン	終了要求時に無限リトライしない／安全に停止する
SIGCHLD	子プロセス終了	wait系がEINTRでも整合が崩れない
SIGALRM	タイムアウト実装（古い設計で多い）	I/O中断時の再試行方針が妥当か
SIGINT	手動オペ（Ctrl+C）	オペ中断時に状態が中途半端に残らない

---

“危ない再現”を避ける：本番同様の負荷をかけない

テストでありがちなのが、再現を急ぐあまり、本番同様の負荷やデータを使ってしまい、テスト環境を壊すことです。EINTRは“環境の相互作用”なので、負荷で無理に引き出すより、シグナルで割り込みを作った方が安全です。ここは無理をせず、軟着陸できる手順で検証しましょう。

---

“この検証が通れば安心”のラインを決める

現場で腹落ちさせるには、「何ができればOKか」を明文化するのが効果的です。たとえば次のような受け入れ条件です。

• 重要な待ち（accept/epoll_wait）がEINTRでも継続し、CPUスピンしない

• 停止シグナル（SIGTERM）時は一定時間で終了に寄せ、ログに理由が残る

• 同一事象が連続した場合にログが増えすぎない（レート制限等）

ここまでが“伏線”です。次章では、その伏線が実際のコードで破綻しやすい典型パターンを整理します。ここを押さえると、EINTRが「たまに起きる面倒」から「直せる設計問題」に変わります。

　

第6章：見落としがちな落とし穴——EINTRを「致命」にする典型パターン（I/O、accept、poll、wait）

EINTRそのものは仕様の範囲内ですが、実装の癖によって「致命」になります。多くの障害は、EINTRが返った瞬間ではなく、その後の処理――つまり“扱い方”で拡大します。ここでは、現場で起きやすい典型パターンを整理し、どういう判断で抑え込みできるかを明確にします。

---

パターン1：EINTRを「例外＝致命」として即終了してしまう

古いコードや短期で書かれたユーティリティでは、-1 ＝失敗、即終了、という単純化が残りがちです。EINTRは「一時中断」なので、待ち系ではリトライで済む可能性が高いのに、即終了してしまうと、監視が再起動→また割り込み→再起動…と、運用全体が不安定化します。結果として、EINTRが“障害の引き金”に見えてしまいます。

---

パターン2：無限リトライでCPUスピンする（終了要求を無視）

逆に、EINTRなら無条件リトライ、を素朴に入れると、停止要求（SIGTERM）が来ても止まらない設計になりがちです。特に、シグナル受信が頻発している状況（子プロセスの終了が連続、監視が介入）では、I/O待ちが成立せず、短いループでEINTR→即リトライが回り、CPUを消費します。これは障害時のダメージコントロールとして最悪の展開です。

---

パターン3：I/Oの意味を無視して“二重実行”してしまう

read/writeは、EINTR以前に一部のデータが処理されている可能性があり、戻り値の扱いが重要です。特にwrite系で、アプリが送信済みかどうかを正しく管理していないと、リトライで二重送信・二重書き込みが起き得ます。結果として、データ整合性の問題が表面化し、「EINTRが原因」という誤った結論に引っ張られます。実際には、EINTRは“きっかけ”で、根はI/O設計の境界にあります。

---

パターン4：poll/select/epollでの“戻り値”と“イベント”の扱いが曖昧

多重化APIは、戻り値が「イベント数」だったり「失敗」だったりし、分岐が複雑になりがちです。ここでEINTRを正しく扱わないと、イベント処理が飛ばされたり、タイムアウト扱いにされたりして、上位の状態機械が崩れます。特に、タイムアウトとEINTRを同列に扱う設計は、原因の切り分けを難しくし、復旧判断の説明を曖昧にします。

---

パターン5：wait/waitpid周りで整合が崩れる

子プロセス連携があるシステムでは、SIGCHLDが絡みます。wait系がEINTRで中断された場合に、単純に「失敗」として扱うと、回収漏れ（ゾンビ）や状態管理の破綻につながります。これは“たまに起きる”からこそ見落とされ、運用のノイズが増えます。ここも、EINTRは原因というより「整合を厳密に扱うべき境界」を示すサインです。

---

典型パターンを“設計判断”に落とす

ここまでをまとめると、EINTRを致命にするのは次の2軸です。

• 継続すべきものを止めてしまう（待ち系を即終了）

• 止めるべきものを止められない（終了要求を無視して無限リトライ）

次章では、この2軸を解消するための「対処の基本形」を、実装と運用の両方にまたがる形で整理します。EINTR対応は“例外処理の穴埋め”ではなく、“境界設計”です。

　

第7章：対処の基本形——再試行ループ、SA_RESTART、そして「どこで再試行してはいけないか」

EINTRを“扱える仕様”にするための基本はシンプルです。（1）再試行する場所を決める、（2）終了要求は尊重する、（3）I/Oの意味（部分完了）を壊さない。この3点を守れば、EINTRが起きても運用が荒れにくくなります。ここでの目的は、例外処理を増やすことではなく、障害対応の議論を収束させるための“一貫した判断基準”を作ることです。

---

基本形1：待ち系（accept/poll/epoll_wait）は「条件付きリトライ」

待ち系は副作用が小さいことが多く、EINTRなら原則リトライが妥当です。ただし、ここで必ず入れるべきなのが停止条件です。現場の本音としては、

「EINTRならリトライでしょ？……でも止めたい時に止まらないのは、それはそれで地獄」

という話になります。停止条件の典型は、SIGTERM受信で立てるフラグ、あるいは上位のキャンセルコンテキストです。無限リトライは“強さ”ではなく、障害時のブレーキを壊す実装になりがちです。

---

基本形2：I/O（read/write）は「戻り値の意味」を最優先する

read/writeは、EINTR以前に何バイト処理されたか、という意味が重要です。EINTR時に常に「0バイト」だと決めつけて二重実行すると、二重送信・二重書き込みなど、整合性の問題に発展します。特にネットワーク送信は「相手が受け取ったか」をアプリ側で完全には保証できないため、アプリケーションプロトコル側の冪等性や再送制御とセットで考える必要があります。

---

基本形3：SA_RESTARTは万能ではない（設計で“依存”しない）

シグナルハンドラに SA_RESTART を付けると、一部のブロッキングシステムコールは自動的に再開され、EINTRが見えにくくなります。ただし、すべてが再開されるわけではなく、ライブラリ・呼び出し形態・カーネル挙動に依存します。つまり「SA_RESTARTにしておけば大丈夫」は、チーム内説明としては弱いです。

現場で揉めない形にするなら、EINTRが“見えた場合”の扱いをアプリ側で定義し、SA_RESTARTは“補助”として扱うのが安全です。EINTRが見える・見えないは環境差の温床になりやすく、説明が難しくなるポイントだからです。

---

「どこで」リトライするか：境界を一本化する

EINTRの取り扱いがコード全体に散らばると、漏れや揺れが出ます。おすすめは、I/Oや待ちの“薄いラッパ層”でEINTRを吸収し、上位は「成功/失敗/キャンセル」を扱う、という分離です。これにより、EINTRを個別実装の癖にせず、設計方針として統一できます。

例として、待ち系のラッパは概念的に次のようになります（擬似的な例です）。

// 例：EINTRはリトライ、停止フラグが立っていれば中断 while (true) { r = epoll_wait(...); if (r >= 0) break; if (errno == EINTR) { if (shutdown_requested) return CANCELLED; continue; } return ERROR; }

ここで大事なのは、EINTRを「握りつぶす」ことではなく、停止要求と区別して扱い、システムの状態遷移を壊さないことです。EINTR対策は“穴埋め”ではなく、“境界の整理”であり、障害対応のノイズカットにつながります。

次章では、その境界整理をさらに進めて、そもそも「シグナルでタイムアウトを作る」などの設計を見直し、割り込みに強い構成へ寄せる考え方を整理します。

　

第8章：設計で潰す——タイムアウト戦略、I/Oモデル、キャンセル可能性を前提にした境界づくり

第7章で「扱い方」を整えましたが、次は一段上の話です。EINTRが頻発する環境では、個別のリトライだけでは運用負荷が残ります。ここで効くのが、設計そのものを“割り込み前提”に寄せることです。言い換えると、EINTRを問題にしているのではなく、EINTRが露出するような境界を場を整える形に作り直す、という方向です。

---

タイムアウトは「シグナル依存」を避けるのが基本

古い設計では、タイムアウト実現のためにSIGALRMを使うことがあります。しかし、SIGALRMはプロセス全体に影響し得るため、I/O待ちとの相互作用でEINTRを生みやすく、診断の難易度も上がります。現代的には、

• poll/epollのタイムアウト（ミリ秒指定）

• ソケット/ライブラリ側のタイムアウト設定

• 上位の期限管理（期限を過ぎたら処理をキャンセル）

など、シグナルではなく“期限”で制御する方針が説明しやすく、運用も安定しやすいです。ここは「EINTRを減らす」というより、障害時の意思決定をクールダウンさせる設計、という意味合いが強いです。

---

I/Oモデル：ブロッキング前提を見直すと“割り込み耐性”が上がる

ブロッキングI/Oは実装が単純ですが、シグナル介入とぶつかるとEINTRが表に出ます。非同期やイベント駆動に寄せるかどうかはトレードオフですが、少なくとも「待ち」を一箇所（イベントループ）に集めるだけでも、EINTRの取り扱いを一本化できます。

たとえば、複数のブロッキング待ちが各所に散っていると、EINTRの扱いが点在し、漏れます。一方、イベントループに集約すると、EINTR対策と停止制御（SIGTERMなど）を統合しやすく、運用の“説明可能性”が上がります。

---

Linuxならではの選択肢：signalfd等で「シグナルをイベントとして扱う」

Linuxには、シグナルをファイルディスクリプタとして扱い、epoll等のイベントループに統合できる仕組みがあります。これを使うと、従来の非同期シグナルハンドラに比べ、状態遷移を明確にしやすいケースがあります。

ただし、ここは万能解ではありません。既存システムがレガシーで簡単に止められない場合、シグナル取り扱いの方式を大きく変えるのはリスクです。導入可否は、運用制約・既存コードの境界・ライブラリ依存とセットで判断すべきで、一般論だけで決めると軟着陸できません。

---

「キャンセル可能性」を先に定義する

EINTR対策が難航する本質は、「止めたい時に止めたい」「でも途中状態は壊したくない」という要求の両立です。ここで必要なのは、処理をどこまで進めたら“取り消し不可”になるか、という境界の明文化です。

例として、次のように境界を定義すると、EINTRを含む割り込み全般に強くなります。

• 外部へ副作用を出す前（送信前、コミット前）はキャンセルしやすい

• 副作用が出た後（送信後、コミット後）は冪等性や再実行戦略が必要

• 終了要求（SIGTERM）を受けたら、新規受付を止め、既存処理は期限付きで完了させる

この整理ができると、EINTRは“割り込み”の一種として、同じ枠組みで扱えます。次章では、ここまでの設計を運用へ落とし込み、アラートや障害報告が過熱しない形に整えます。

　

第9章：運用で再発を防ぐ——ログ粒度、アラート条件、障害報告の“説明可能性”を上げる

設計と実装を整えても、運用が追いつかないと現場は楽になりません。EINTRは「起きたこと」より、「起きた時に誰がどう判断したか」が問われます。ここを整えると、障害対応の議論が過熱しにくくなり、復旧が収束しやすくなります。

---

ログは「詳細」より「意思決定」を残す

ログに残すべきは、技術詳細の羅列ではなく、判断の根拠です。たとえば、EINTRを検知したときに、

• リトライした（継続可能）

• 停止要求があるため中断した（安全停止へ）

• 別エラーのため中断した（原因はEINTRではない）

のどれなのかが分かるだけで、報告資料の作りやすさが変わります。現場の“心の会話”としては、

「原因の説明を求められても、根拠がログに残ってないと詰むんだよな……」

という苦しさがあるはずです。ここを“穴埋め”するのが運用設計です。

---

アラート設計：EINTR単体で鳴らさない

EINTRは仕様の範囲内なので、EINTRが1回出たこと自体でアラートを上げると、ノイズになります。アラートは「サービス品質に影響している兆候」に寄せるのが基本です。たとえば、

• EINTRが連続し、処理遅延やスループット低下が出ている

• 停止要求が出ているのにプロセスが終了できない（無限リトライ疑い）

• 特定の重要経路でEINTRが集中している（accept/epoll_waitが回らない等）

といった条件にすることで、アラートが“現場のブレーキ”ではなく、被害の被害最小化に寄与する信号になります。

---

運用手順（ランブック）に落とす：5分でやることを決める

障害時は時間がありません。EINTR系の切り分けで、まず5分でやることを固定化すると強いです。

1. 直近ログから「どのシステムコール相当の操作か」を特定

2. 停止要求（SIGTERM等）の有無、デプロイ/再起動イベントの有無を確認

3. 必要なら限定時間でstraceを取る（“割り込みの瞬間”を保全）

4. 連続発生か単発か、サービス影響（遅延/失敗率）を確認

この手順があるだけで、「EINTRが出た」から「原因不明で大騒ぎ」への連鎖に歯止めがかかります。EINTRは“トラブルの証拠”であると同時に、“運用を整えるきっかけ”にもなります。

---

一般論の限界：環境差が結論を変える

ここまでの話は、あくまで設計・運用の一般原則です。しかし、現実の案件では、カーネルやlibc、ランタイム、コンテナ基盤、監視・デプロイ方式、アプリのI/Oモデルなどが絡み、どこに手を入れるのが最も効果的かは変わります。たとえば「EINTRが増えた」という事象でも、原因が

• デプロイ頻度の変化

• 子プロセス連携の追加

• タイムアウト実装の変更

• ライブラリ更新でシグナル周りの挙動が変化

といったように異なれば、最適な“抑え込み”ポイントも変わります。ここから先（次章）は、一般論を踏まえたうえで、個別案件の判断が必要になる局面を整理し、自然に株式会社情報工学研究所のような専門家相談へつなげます。

　

第10章：帰結——EINTRは敵ではなく「割り込みに耐える設計」をチェックするリトマス試験紙

EINTR（Interrupted system call）は、Linux/UNIX系の運用では避けがたい現象です。ここまで見てきた通り、EINTRは「何かが壊れた」ではなく、「ブロッキング中のシステムコールがシグナルで中断された」という事実を示します。つまり、EINTRが出た瞬間に問われるのは“原因究明力”よりも、割り込みが来ても破綻しない境界設計と、判断を説明できる観測です。

---

技術的な帰結：EINTR対応は「例外処理」ではなく「停止・再試行・整合性」の設計

現場でEINTRが問題化するのは、次の3つが曖昧なときです。

• 再試行：EINTRのときに、どこでリトライするのか（散らばっていないか）

• 停止：SIGTERMなどの終了要求をどう扱うのか（止めたい時に止められるか）

• 整合性：I/Oが部分完了し得ることを前提に、二重実行や中途半端を防げるか

この3点が揃っていれば、EINTRは「たまに出る厄介なログ」から、「割り込みが来たことを示す観測点」になります。議論も過熱しにくく、復旧も収束しやすくなります。

---

現場の帰結：説明可能性があると、障害対応の“空気”が変わる

障害時に本当に削りたいコストは、実は実装工数よりも“説明コスト”です。EINTRに限らず、現場の本音はこうです。

「正しいことをやってても、説明ができないと、次の障害でまた同じ揉め方をするんだよな……」

だからこそ、EINTRの対処は「ログに意味を残す」「5分で切り分けできるランブックを作る」「停止要求の挙動をテストで保証する」といった、運用と設計をまたぐ取り組みになります。ここが整うと、単発の対処で終わらず、継続的にノイズカットされていきます。

---

導入・改善の現実：一般論だけでは最適解が決まらない

ただし、ここからが重要です。EINTRは“環境の相互作用”で見え方が変わります。たとえば、同じアプリでも次の条件で挙動や優先順位が変わります。

• プロセス管理（systemdか、コンテナ基盤か、独自ランチャか）

• デプロイ方式（ローリング更新、即時再起動、スケールインの頻度）

• 使用ライブラリやランタイム（スレッドモデル、シグナルの扱い）

• I/Oモデル（イベントループ集中か、各所ブロッキングか）

• 外部連携（子プロセス起動、バッチ、監視介入）

つまり、同じ「EINTRが出た」という現象でも、“どこを直すのが最短でダメージコントロールになるか”は個別に変わります。一般論で「とにかくリトライ」や「SA_RESTARTで解決」と決め打ちすると、止めたい時に止まらない、整合性が崩れる、ログが汚れる、といった二次的な問題を生みやすいです。ここが一般論の限界です。

---

自然な次の一歩：個別案件は専門家と一緒に“設計の落としどころ”を決める

もしあなたの現場が、

• 既存システムがレガシーで簡単に止められない

• 本番だけでEINTRが見え、再現が難しい

• 停止（SIGTERM）とリトライの設計が曖昧で、運用が不安

• I/Oの整合性（部分完了・二重実行）が怖くて手が出せない

といった状況なら、一般論の知識だけで抱え込むより、現場制約に合わせて「どこで」「どの条件で」「何を優先して」対処するかを一緒に決めた方が、結果的に早く被害最小化できます。案件・契約・システム構成の制約を踏まえた判断が必要な場面では、株式会社情報工学研究所のような専門家へ相談し、観測設計・停止設計・I/O境界設計をセットで見直すことを検討してください。

　

付録：主要プログラミング言語・実行環境ごとのEINTR注意点（現場でハマりやすい所）

同じLinux上でも、言語・ランタイム・標準ライブラリがEINTRをどう扱うかは一様ではありません。ここでは「一般論の範囲で言える注意点」を整理します。最終的な挙動は、OS/バージョン/ライブラリ/設定/実装に依存するため、個別案件では観測（ログ/strace等）で確認してください。

---

C / C++（POSIX直叩きが多い領域）

• 戻り値とerrnoを厳密に扱う：-1 のとき必ずerrnoを確認し、EINTRなら「リトライ or 終了」の方針に従う。

• SA_RESTARTに依存しすぎない：一部システムコールは自動再開されない場合があるため、EINTRが見える前提の設計も残す。

• I/Oは部分完了を前提に：read/writeの戻り値（処理済みバイト数）を無視した“単純リトライ”は整合性を壊し得る。

Rust（標準ライブラリ＋OS依存層）

• 抽象化の下でEINTRが握りつぶされる/露出する差：標準ライブラリや依存クレートが内部で再試行する場合がある。ログやエラーハンドリング設計は「見える/見えない」差を前提に。

• 低レベルI/O（nix等）を使う箇所は方針統一：混在すると、同じ現象でも挙動が揃わず説明が難しくなる。

Go（ランタイムがI/Oを抽象化することが多い）

• シグナルはos/signalで扱うのが基本：停止（SIGTERM）とアプリのシャットダウン設計（contextキャンセル等）を明確に。

• 直接syscallを触る箇所は特に注意：通常のネットワークI/Oと、低レベルsyscall混在で挙動差が出ると切り分けが難しい。

• “止めたい時に止まる”設計を先に：EINTR以前に、Graceful shutdownが曖昧だと運用が荒れやすい。

Java / Kotlin（JVM）

• 例外がEINTRとして直接見えないことが多い：I/Oは例外として表出したり、内部で再試行されたりする。OSレベル原因を疑う場合はstraceなど外部観測が重要。

• 割り込み（interrupt）との混同に注意：スレッド割り込みとOSシグナルは別概念。設計・運用で混線させない。

• 停止はシグナル→プロセス終了、アプリはShutdownHook等：運用（systemd/コンテナ）との連携を前提に停止経路を一本化。

Python（CPython）

• 例外（InterruptedError等）として見える場合がある：低レベルI/Oや一部APIでEINTR相当が例外化されることがあるため、例外処理の方針を統一する。

• シグナル処理はメインスレッド中心：スレッドや非同期処理と組み合わせると、停止設計が曖昧になりやすい。

• サードパーティI/O（requests等）は内部実装差が出る：障害時は“どの層で止まっているか”を観測で切り分ける。

Node.js / JavaScript（Nodeランタイム）

• イベントループ中心でEINTRが表に出にくい一方、停止設計が重要：SIGTERMを受けたときに新規受付停止・接続クローズ・期限付き終了を設計する。

• ネイティブアドオンやchild_process連携で露出：外部プロセス起動やネイティブ層が絡むと、OSレベルの挙動が見えやすくなる。

PHP（FPM/CLI/拡張の影響が大きい）

• 実行形態で性質が変わる：FPM配下、CLI、常駐（ワーカー）などで停止・再起動の設計ポイントが異なる。

• 拡張や外部I/Oの層で挙動差：同じ“EINTRっぽい現象”でも、どの拡張（curl等）を通っているかで切り分けが変わる。

C# / .NET

• 例外として抽象化されることが多い：OSのEINTRそのものより、“キャンセル/停止/タイムアウト”の設計で破綻しないことが重要。

• ホスティング環境（systemd/コンテナ/サービス）との停止連携：停止イベントで確実に終了できるよう、期限と後処理を設計する。

Ruby

• 例外としての表出に注意：I/O待ちや外部コマンド連携で割り込みが表に出る場合がある。救済（rescue）で握りつぶして“無限継続”しない。

• 運用イベント（再起動/ローテ）との相関を見える化：EINTRは単体で追うより、運用ログと合わせて説明可能性を上げる。

---

付録のまとめ：言語差より「境界設計」と「観測」が勝つ

どの言語でも共通するのは、EINTR（割り込み）を“ゼロにする”ことより、割り込みが来ても

• 継続すべき処理は継続できる

• 止めるべき時に止められる

• 整合性が壊れない

• 判断の根拠がログで説明できる

という形に整えることです。ここは一般論のテンプレだけでは決め切れない場面が多く、既存資産・契約条件・運用制約・基盤構成によって最適解が変わります。具体的な案件として「どこに手を入れるのが最小コストで最大効果か」を詰めたい場合は、株式会社情報工学研究所への相談・依頼を検討してください。