Linux EDEADLK (35) 対策：Resource deadlock avoided エラーの原因解析とロック順序最適化編

選択と行動:
同一スレッド再取得の有無を確認し、recursive化で逃がす前に呼び出し経路を整理。
最小変更でロック位置を1か所に寄せられるなら、その案を優先。

選択と行動:
ロック階層を定義し、取得順を固定。
影響範囲が広い場合は、まず高頻度経路から順序統一を始める。

選択と行動:
ログ追加・統計取得・限定的な検証で根拠を先に集める。
最小変更で収まらない場合は、設計レビューを挟んで進める。

【注意】 Linux の EDEADLK (35) や「Resource deadlock avoided」が出ている場面では、自己判断で本番系のロック実装・共有領域・データ配置・運用中ジョブを触ってしまうと、待機の連鎖や障害範囲の拡大につながるおそれがあります。まずは新たな修理や復旧作業を進めず、ログ保全・再現条件の整理・変更凍結などの安全な初動にとどめ、個別の契約条件や監査要件、本番構成が絡む場合は、株式会社情報工学研究所のような専門事業者へ相談してください。問い合わせフォーム：https://jouhou.main.jp/?page_id=26983　電話：0120-838-831

第1章：なぜ Linux の EDEADLK (35) は突然出るのか――現場で起きる「止められないのに止まる」違和感

「昨日まで動いていたのに、ある条件だけで EDEADLK (35) が出る」「完全停止ではないのに “Resource deadlock avoided” と出て、担当者説明が難しい」。この違和感は、現場の感覚として非常に自然です。Linux や POSIX 系のロックでは、実際に処理が固着したあとでしか問題が見えない場合もあれば、実装や属性によっては“このまま待機させると危ない”と判断され、エラーとして返される場合もあります。たとえば POSIX の pthread_mutex_lock() では、EDEADLK は「デッドロック状態が検出された」と定義されており、Linux man-pages でも error-checking mutex を同一スレッドが再取得した場合には即座に EDEADLK を返す挙動が示されています。つまり、このエラーは「もう完全に詰まった」という意味だけでなく、「詰まりに向かう経路を検出して収束方向にブレーキがかかった」サインとして読む必要があります。

この論点が厄介なのは、現場で見えている症状と、ロック実装が内部で判断していることが一致しない場合があるからです。PTHREAD_MUTEX_NORMAL では再ロック時にデッドロック検出を提供しない一方、error-checking mutex では同一スレッド再取得を検知して EDEADLK を返す、という差があります。したがって、同じ「二重にロックしていそうなコード」でも、mutex 属性やライブラリ設定次第で、ある環境では固着として現れ、別の環境ではエラーとして顕在化します。現場で「本番だけ雰囲気が違う」「検証では止まるのに本番ではエラーで返る」「逆に本番では沈静化せず待ち続ける」といった説明の難しさが出るのは、この差が背景にあるためです。

まず先に押さえたいのは、「症状 → 取るべき行動」を混同しないことです。EDEADLK は“直し方の名前”ではなく、“今ある競合の兆候”です。そのため、いきなり recursive mutex に切り替える、ロックを外側へ移す、trylock に置き換える、といった変更を急ぐよりも、どのスレッド・どの関数経路・どの共有資源で衝突しているのかを整理した方が、結果として被害最小化につながります。特にレガシーなサーバや止めにくい業務システムでは、修正そのものよりも「どこまでが影響範囲か」を読み違えないことが重要です。

ファイルロックの文脈でも、EDEADLK は実務上かなり重要です。POSIX の lockf() では、システムがデッドロック発生を検出した場合に EDEADLK を返すとされていますし、Linux の record locking の文脈でも、協調的なロック運用の中で待機関係が循環したときは「避けられたデッドロック」として扱う必要があります。ここでありがちな誤解は、「エラーで戻ったのだから大事ではない」と見ることです。しかし実際には、エラーで戻ったこと自体が、防波堤として機能しただけかもしれません。もし同じ競合が別の経路、別の属性、別のタイミングで発生すれば、今度は素直に待ち続けて業務影響へ発展する可能性があります。

この章の時点での結論は明確です。EDEADLK (35) は、単なるノイズではなく、ロック設計・呼び出し順・運用前提のいずれかに歯止めが必要だというサインとして受け止めるべきです。そして、ここで重要なのは「すぐ大きく直すこと」ではなく、「安全な初動で場を整えること」です。具体的には、発生時刻、対象処理、対象資源、スレッド情報、直前の変更、mutex 属性やロック方式の確認を先に進め、安易な実装修正は後ろへ回す方が、説明責任の面でも再発防止の面でも有利です。個別案件では、共有ストレージ、コンテナ、本番データ、監査要件、停止許容時間によって正しい判断が変わります。一般論だけで押し切れないと感じた段階で、株式会社情報工学研究所のように実運用と設計変更の両面を見られる専門家へ相談することが、結果として収束を早める近道になります。

第2章：まず切り分けたい論点――実デッドロックと「Resource deadlock avoided」の違い

Linux で EDEADLK (35) を見たとき、最初に整理したいのは「すでに処理が詰まっているのか」と、「詰まりに向かう待機を実装側が避けてエラーで戻したのか」は同じではない、という点です。ここを混同すると、現場での判断がぶれます。pthread_mutex_lock() の仕様では、PTHREAD_MUTEX_ERRORCHECK 型の mutex を、その所有スレッドが再度ロックしようとした場合、EDEADLK を返します。一方、通常の mutex では同じ状況で待機に入り、結果として呼び出しスレッドが自分で自分を待つ形になりえます。つまり、同じ「同一スレッドが再度ロックした」状況でも、属性次第で“エラーとして見える”こともあれば、“固着として見える”こともあります。したがって、EDEADLK が出たからといって、常に複数スレッド間の循環待機を意味するわけではありません。まずは mutex 属性と所有関係を確認する必要があります。

この違いは、現場での説明責任に直結します。たとえば障害報告で「デッドロックが発生した」とだけ書くと、読み手は通常、複数のスレッドやプロセスが相互待機に入って業務が止まる状態を想像します。しかし実際には、error-checking mutex が同一スレッドの再取得を検知して、そこに至る前にブレーキをかけているだけかもしれません。この場合の本質は、「安全に見えるエラー処理の裏に、再入設計や責務分離の乱れが隠れている」ことです。逆に、ロック取得順の逆転が複数経路にまたがっている場合は、今回たまたまエラーとして収束していても、別条件では待機が連鎖して本格的な停止に至る可能性があります。エラー文言だけで軽重を決めず、どの層で検知されたものかを見分ける視点が欠かせません。

ここで、実務上の切り分けをしやすくするために、症状と判断軸を分けて見ていきます。重要なのは「修正案」を急いで選ぶことではなく、「このエラーがどの種類の待機を示しているのか」を先に確定させることです。とくに止めにくいシステムでは、診断が曖昧なまま mutex 種別の変更やロック順序の書き換えを入れると、目先のメッセージだけ消えて、別の待ち時間増大やスループット低下を招くことがあります。

ファイルロックでも同様の考え方が必要です。POSIX の fcntl() 系ロックでは、あるプロセスが他プロセスのロック解放待ちに入り、その待機関係が循環してデッドロックになるとシステムが判断した場合、EDEADLK を返すとされています。つまり、mutex の自己再取得とは違い、こちらはプロセス間・領域間の待機循環をシステムが検出している文脈です。アプリケーションログで同じ EDEADLK という値が見えても、背後にある競合構造はまったく異なる可能性があります。共有ファイル、ジョブ制御、バッチ連携、複数ワーカーの同時更新が絡むときは、pthread の話だけで判断を閉じない方が安全です。

そのため、切り分けの入口では、少なくとも次の四点を押さえると判断がぶれにくくなります。

• 問題のロックが pthread mutex なのか、fcntl/lockf などのファイルロックなのか。
• 同一スレッド再取得の可能性があるのか、別スレッド・別プロセスとの循環待機なのか。
• mutex 属性が NORMAL、ERRORCHECK、RECURSIVE のどれなのか。
• エラーで戻っているのか、待機したまま応答が落ちているのか。

この四点が曖昧なまま対策だけを選ぶと、設計変更の方向を誤りやすくなります。たとえば、error-checking mutex で顕在化した自己再取得を見て、単純に recursive mutex に変更すると、メッセージは消えるかもしれません。しかしそれは、呼び出し階層の責務重複やロック境界の曖昧さを温存する選択になりえます。POSIX 仕様でも recursive mutex はロック回数を数え、同数の unlock が必要になる前提です。したがって、設計意図なく採用すると、アンロック漏れや保守性低下の温床になります。逆に、複数ロック間の順序逆転が原因なのに「同一 mutex の話だろう」と見誤ると、局所修正では収まらず、低頻度障害が残り続けます。

実務では、ここで「では何を先にやるべきか」が気になるところですが、答えは比較的明確です。最初の目的は“修理”ではなく、“依頼判断に足る材料を整えること”です。つまり、ログの時系列、対象関数、対象ロック、スレッドIDやプロセスID、対象データ、直前変更、運用条件をそろえ、どの種類の競合なのかを説明可能にすることが先です。これにより、現場内で対応を続けるべき案件なのか、構成・契約・監査・可用性要件まで含めて専門家へ相談すべき案件なのかが見えてきます。特に、本番データを扱う共有ストレージ、複数コンテナ、ジョブスケジューラ、夜間バッチ、監査証跡が絡む場合は、一般論のコード修正だけで安全性を担保しにくくなります。

この章の結論として、EDEADLK と「Resource deadlock avoided」は、単に“怖いエラー”として一括りにせず、「自己再取得の検知なのか」「循環待機の検知なのか」「待機に入る前の抑え込みなのか」を分けて読むことが重要です。そうすることで、場当たり的な実装修正ではなく、最小変更で収束を目指す判断がしやすくなります。個別案件では、アプリケーション設計、運用制約、停止許容時間、監査要件まで含めて見ないと正しい対処が決まりません。一般論だけで押し切るのが難しいと感じた時点で、株式会社情報工学研究所のような専門家へ相談し、影響範囲の見立てと対策方針を早めに固めることが、結果としてダメージコントロールにつながります。

第3章：原因を深掘る視点――再入・自己待機・ロック順序逆転が潜む典型パターン

Linux の EDEADLK (35) を正しく扱うには、「どの場面でそのエラーが起きやすいのか」を、実装パターンごとに分けて見ることが重要です。特に実務で頻出なのは、同一スレッドによる再入、自己待機、複数ロックの順序逆転、そしてファイルロックの循環待機です。pthread_mutex_lock() の仕様では、error-checking mutex に対して現在のスレッドがすでに所有している mutex を再度ロックしようとすると EDEADLK が返ります。一方、recursive mutex ではロック回数が加算され、対応する回数だけ unlock するまで解放されません。つまり、見えているエラーコードが同じでも、「設計の破綻を検知している」のか、「再帰的ロックを許す設計か」で意味が変わります。まずは、いまのコードがどの mutex 種別を前提にしているのかを確かめることが出発点になります。

最初の典型パターンは、関数の責務が重なった結果として起きる「意図しない再入」です。たとえば、上位関数でロックを取得したあと、共通処理として切り出した下位関数が同じ mutex を再度取りにいく構成は、レガシーコードや保守改修の積み重ねでよく生まれます。このとき error-checking mutex なら EDEADLK が返り、fast や normal 系ではそのまま自分自身を待ってしまう実装がありえます。Linux 系の man page でも、error checking では即時 EDEADLK、fast kind では実質的に calling thread が deadlock する旨が示されています。したがって、「EDEADLK が出たから障害が重い」のではなく、「そのコードは別設定なら待機で表面化していた可能性がある」と読む方が、保守上は正確です。

二つ目の典型パターンは、「自己待機」です。これは一見すると再入と似ていますが、現場では少し違う形で現れます。たとえば、コールバック、シグナル処理、イベント通知、エラーハンドリング経路の中で、元の呼び出し元と同じ保護対象に触れてしまうケースです。設計上は別の責務として分かれているつもりでも、共有状態の保護境界が曖昧だと、結果として同じ mutex や同じファイル領域に戻ってきてしまいます。この種の問題は、ソースコードを一画面だけ見ても気づきにくく、ログ時系列やスタックの流れを追わないと見落とされがちです。しかも、メッセージ上は「デッドロック回避」と表示されるため、現場では一時的なノイズと受け取られやすい傾向があります。しかし実際には、処理の責務分離が崩れ始めているサインであり、ここを放置すると別経路で待機時間の増加やスループット低下として表面化しやすくなります。error-checking mutex が返す EDEADLK は、その崩れを比較的早い段階で見せてくれていると理解した方が安全です。

三つ目は、複数ロックの「取得順序逆転」です。これは、A の経路では L1 を取ってから L2 を取り、B の経路では L2 を取ってから L1 を取る、という形で発生します。こうした循環待機は、複数スレッドや複数プロセスが関わると断続的で説明しにくくなります。ファイルロックでは、カーネルがこうした待機循環を検出すると、一方の blocking lock request を EDEADLK で失敗させると man page に明記されています。また、二つ以上のプロセスにまたがる循環も検出対象になりますが、検出アルゴリズムには限界があることも同時に示されています。つまり、「一度 EDEADLK で戻ったから安心」ではなく、検出できた局面だけが抑え込まれたにすぎず、別条件では普通に長時間待機へ移行する余地があります。

四つ目は、「recursive mutex に逃がせばよい」という誤解です。確かに recursive mutex は同じスレッドによる複数回の lock を許可し、lock count を持ちます。しかし、それは「設計上それが必要だと分かっている場合」にだけ意味があります。POSIX 仕様でも、recursive 型では対応する回数だけ unlock しなければ解放されません。つまり、ロック境界が曖昧なまま recursive 化すると、今度は unlock 回数管理が複雑になり、別の不整合や保守負荷を招きます。EDEADLK を消すこと自体が目的になると、本来整理すべき責務の重複やロック境界の不明瞭さが残り、あとで大きな見直しを要することがあります。見た目のクールダウンと、設計上の解消は同じではありません。

もう一つ実務で見落とされやすいのが、「mutex 以外のロックが混ざっている」ケースです。アプリケーション側では pthread mutex を使い、別の層では fcntl のレコードロックを併用している構成では、待機の連鎖がソースコードの一箇所だけでは見えません。たとえば、アプリケーションロックを保持したままファイルロック待ちに入り、その相手側プロセスは逆にファイルロックを保持したまま API 経由でアプリケーションロック待ちに入る、といった形です。カーネルは process-associated record locks に対して deadlock detection を行いますが、その検出には限界があります。したがって、ログ上の EDEADLK をファイルロック起因と見抜けないと、アプリケーション内の mutex だけを見直しても十分な収束にはつながりません。

原因解析の段階では、次のような観点で材料をそろえると、個別案件の判断精度が上がります。

• どの lock API が返している EDEADLK かを特定する。
• 同一スレッド再取得か、複数主体の循環待機かを切り分ける。
• mutex 属性、lock count、unlock 対応関係を確認する。
• ロック保持中に別層の I/O、コールバック、通知処理へ出ていないかを見る。
• 共有ファイル、ジョブ、ワーカー、コンテナ間で競合主体が増えていないかを確認する。

この章の結論として、EDEADLK の背景は一種類ではなく、「再入の設計不整合」「自己待機」「順序逆転」「ファイルロック循環待機」といった複数の典型パターンに分けて考える方が、原因を見誤りにくくなります。一般論として mutex 種別を変える、trylock を増やす、ロックを減らすといった話はできますが、実際の案件では停止許容時間、共有ストレージ、本番データ、外部連携、監査要件が絡みます。そのため、現場だけで対症的に抑え込みを図るより、構成全体を見て影響範囲を診断できる専門家の支援を早めに入れた方が、結果として収束が早いケースは少なくありません。判断が割れる場合や、設計の責務境界まで踏み込んだ整理が必要な場合は、株式会社情報工学研究所への相談・依頼を検討する価値があります。

第4章：ログとコードで追い込む――影響範囲を広げずに再現条件と競合箇所を特定する

Linux の EDEADLK (35) を原因解析するとき、現場で最も重要なのは「いきなり直す」よりも、「どのロック経路で、どの条件のときに、どの主体同士がぶつかったのか」を説明できる状態へ持っていくことです。pthread_mutex_lock() の仕様上、EDEADLK はデッドロック状態の検出として返りえますし、error-checking mutex では呼び出しスレッドがすでに所有する mutex の再取得でも返りえます。また、fcntl()/lockf() 系では、ブロッキングロック要求が待機循環を作るとカーネルが EDEADLK を返す場合があります。つまり、同じエラーコードでも、観測すべき材料は API によって違います。ここを分けて記録しないと、あとで分析が混ざります。したがって、最初にすべきことは、どの API が返した EDEADLK なのか、対象が mutex なのかファイル領域ロックなのか、関数名レベルで特定することです。

この段階で避けたいのは、再現前にロック位置を大きく動かすことです。たとえば「ここが怪しい」と感じた関数の lock/unlock を別レイヤーへ移したり、mutex 属性を変更したりすると、もともとの待機構造が見えなくなります。error-checking で見えていた自己再取得が、別の mutex 種別では待機や無反応としてしか見えなくなることもあります。そのため、初動では“設計変更”ではなく“観測点の追加”を優先した方が、結果として収束しやすくなります。ログは、エラーそのものだけでなく、ロック取得の直前、取得成功直後、解放直前、解放直後に入れるのが基本です。加えて、スレッドID、プロセスID、対象リソース識別子、呼び出し元関数、相関ID、処理モード、本番データか検証データかを残すと、あとから待機関係の線が引きやすくなります。

実務で有効なのは、「ロックの事実」ではなく「順序」を見える化することです。単に “lock failed with EDEADLK” とだけ出しても、再入なのか順序逆転なのかが分かりません。そこで、ロック名やアドレスだけではなく、どの順で取得しようとしたかをログで追えるようにしておくと分析が進みます。たとえば L1 を取得済みの状態で L2 を取りに行ったのか、あるいは L2 取得済みで L1 に戻ってきたのかが見えるだけでも、順序逆転の有無がかなり絞れます。ファイルロックでも同様で、どの fd、どの範囲、read lock か write lock か、blocking か nonblocking かを分けて記録すると、相手側プロセスとの循環待機の可能性が見えてきます。Linux の fcntl_locking の文書でも、F_SETLKW による待機ではカーネルが deadlock detection を行う一方、検出には限界があるとされています。したがって、カーネルの返す EDEADLK だけに頼らず、アプリケーション側で待機構造を再構成できるログを持っておくことが重要です。

コードの追い方にも順番があります。まず確認したいのは、mutex 初期化時にどの属性を使っているかです。PTHREAD_MUTEX_DEFAULT や NORMAL に近い扱いか、ERRORCHECK か、RECURSIVE かで、同じコードでも見え方が変わります。Open Group の仕様でも、recursive mutex は lock count を増やし、error-checking mutex は所有スレッドによる再ロックで EDEADLK を返すことが示されています。したがって、呼び出し元から末端関数までをなぞるときは、「同じ mutex を二回触っているか」だけではなく、「その二回目がどの mutex 種別上でどう扱われるのか」まで見ておく必要があります。単に “二回 lock している” と言っても、設計上許容された再帰的利用なのか、責務の重複なのかで、対処方針は変わります。

次に、ロック保持中に外へ出ていないかを確認します。ここでいう「外」とは、I/O、コールバック、イベント通知、別スレッドへの同期呼び出し、共有ファイルアクセスなどです。原因が見つからない案件では、mutex 自体よりも「ロックを持ったまま別の待機要因へ踏み込んでいる」ことが少なくありません。たとえば、共有状態を保護する mutex を保持したままファイルロック待ちに入る、あるいはログ出力経由で別のロック取得へつながる構成は、局所的には安全に見えても全体では循環待機を作ることがあります。特に flock() と fcntl() は性質が異なり、Linux の flock(2) は deadlock detection を行わない一方、traditional POSIX fcntl locks では deadlock detection が働きます。したがって、ファイルロックの実装差を意識せずに「どちらも同じロック」と捉えると、観測設計を誤りやすくなります。

再現条件の詰め方も、影響範囲を広げない順で進める方が安全です。実務では、いきなり本番相当の高並列試験を走らせるのではなく、まずは発生時の入力条件、対象データ種別、同時実行数、ジョブ起動タイミング、外部連携有無、失敗時刻帯などの共通項を整理します。そのうえで、変更を最小限に抑えたログ追加版を限定環境に入れ、同じ系統の呼び出しを再現できるかを確認します。もし本番でしか出ないなら、本番では“直すための変更”より“観測のための変更”を優先し、件数・時間帯・対象処理の傾向を集める方が賢明です。EDEADLK は、発生件数の少なさに安心して見過ごされがちですが、実際には頻度よりも「条件の狭さ」が問題です。条件が狭いだけで、本質は構造的競合であることが珍しくありません。

また、原因解析時には「このコードだけ見れば正しい」という局所判断にも注意が必要です。各関数が個別には正しそうでも、上位層との組み合わせで順序逆転が起きることがあります。そこで有効なのが、関数単位のレビューではなく、「ロック資源ごとの入出表」を一度作ることです。どの関数が、どのロックを、どの順で、どの条件で取得し、解放までに何を呼ぶのかを簡単な表にするだけでも、暗黙の順序ルールが崩れている箇所が見えやすくなります。これは実装担当者だけでなく、リーダーや関係部署へ説明する材料としても有用です。単なる感覚論ではなく、「L1 保持中に L2 へ進む経路が三つあり、そのうち一つだけ逆順で戻る」といった形で示せれば、対策の優先度も決めやすくなります。

最後に、依頼判断の観点を明確にしておくことが重要です。EDEADLK の解析が、単純なコード整理で済むのか、それとも構成全体の診断が必要なのかは、次の条件で分かれやすくなります。

• 共有ストレージやファイルロックを複数プロセスで使っている。
• コンテナ、ジョブ、API、バッチが同じデータを触っている。
• 本番停止の許容時間が短く、検証を何度も回せない。
• 監査要件や説明責任があり、再発防止の根拠まで求められる。
• ロック順序の変更が複数チーム・複数機能へ波及する。

これらに当てはまる場合、一般論としての「mutex を見直す」「ログを増やす」だけでは足りず、影響範囲の診断と変更計画まで含めた支援が必要になりやすいです。この章の結論として、EDEADLK の原因解析は、エラー文言の解釈だけではなく、ログ設計、コード経路、ロック属性、ファイルロック方式、運用条件を重ねて追うことで初めて精度が上がります。そして、最小変更での収束が求められる案件ほど、個別事情を踏まえた見立てが重要になります。社内だけで材料整理が難しい場合や、対策の影響範囲に不安がある場合は、株式会社情報工学研究所のような専門家へ相談し、原因特定と依頼判断を並行して進めることが現実的です。

第5章：ロック順序をどう最適化するか――最小変更で安全性と保守性を両立する設計

Linux の EDEADLK (35) への対策で最も難しいのは、「何を変えるか」よりも「どこまで変えずに済ませるか」を見極めることです。pthread_mutex_lock() の仕様では、NORMAL 系では再ロックがデッドロックになり、ERRORCHECK ではエラーが返り、RECURSIVE では lock count が増えるという違いがあります。つまり、同じ現象に見えても、mutex 種別を変えるだけで表面症状が変わります。そのため、ロック順序の最適化は、単にエラーを消す作業ではなく、「待機構造を単純化し、説明可能にする」作業として考える方が安全です。見た目だけを静かにしても、順序の揺れや責務の重なりが残っていれば、別条件で再発する余地が残ります。

最小変更で収束を目指すとき、優先順位は比較的はっきりしています。第一に、同じ共有資源に対するロック取得順を全経路で統一することです。第二に、ロック保持中に別の待機要因へ出ないようにすることです。第三に、どうしても再入が必要な箇所だけを設計意図とともに明文化することです。POSIX の仕様表でも、mutex type ごとに relock 時の振る舞いが異なりますが、設計上の安定性という観点では「取得順が決まっている」ことの方が効きます。L1 のあとに L2 を取るなら、すべての経路で L1→L2 に揃える。この単純な原則が、現場では最も強い防波堤になります。

ロック順序の最適化でありがちな失敗は、「問題が出た箇所だけを局所的にずらす」ことです。たとえば、ある関数だけ lock の位置を前後に動かして、一時的に EDEADLK を見えなくする方法は、短期的には魅力的に見えます。しかし、その変更が別経路の順序ルールを壊すと、別の時間帯や別の機能で待機の連鎖を生みます。特に複数ロックを使う系統では、関数単位の正しさより、システム全体での順序一貫性の方が重要です。そこで有効なのが、「ロック階層表」を先に作ることです。たとえば、設定情報の mutex は最上位、セッション情報は中位、個別リソースのロックは下位、といった形で階層を決め、上から下へしか取得しない方針を全体に適用します。これは大規模な作り直しではなく、既存コードの暗黙ルールを明文化する作業に近いため、最小変更と相性が良い進め方です。

ここで大切なのは、「RECURSIVE に変えるかどうか」は最後に考えることです。POSIX の仕様では、RECURSIVE mutex は relock 時に lock count を増やし、count が 0 になるまで他スレッドに解放されません。この性質は、再帰呼び出しや明示的な再入が設計上必要な場面では有効です。しかし、もともと ERRORCHECK で見えていた問題を隠すためだけに RECURSIVE へ変更すると、今度は unlock 対応関係が複雑になり、保守で読み解きにくくなります。局所的な抑え込みには見えても、設計の説明可能性は下がりやすいという点を見落とせません。

一方で、ファイルロックが絡む場合は、アプリケーション内の順序だけを整えても十分ではありません。Linux の fcntl の record locking では、F_SETLKW による待機中、カーネルが deadlock detection を行い、循環待機を検出すると一方を EDEADLK で失敗させます。しかし man page には、検出アルゴリズムが false negative と false positive の両方を起こしうること、依存探索深さに制限があること、CLONE_FILES を使うプロセス群では誤検知が起こりうることまで記載されています。つまり、「カーネルが見つけてくれるから順序整理は不要」とは言えません。アプリケーションロックとファイルロックの両方がある場合は、層をまたいだ取得順も意識して、少なくとも “アプリケーションロック → ファイルロック” なのか “ファイルロック → アプリケーションロック” なのかを統一する必要があります。

では、実務で取りやすい順序最適化の進め方は何かというと、全面刷新より「狭い範囲で効果の高い順」に並べるのが現実的です。まず、高頻度で通る経路と障害時に必ず関わる経路だけを対象に、ロック取得順を棚卸しします。次に、その経路のうち逆順が存在する箇所だけを洗い出します。そして、逆順を解消するために、取得順を合わせるか、ロック粒度を分離するか、ロック保持中の呼び出しを外へ出すかを比較します。このとき、「コード差分が小さい」だけで案を選ばず、「運用影響が読めるか」「説明責任を果たせるか」を含めて決める方が失敗しにくくなります。止めにくいシステムほど、技術的な正しさだけではなく、導入時の軟着陸が重要になるからです。

特に注意したいのは、trylock を多用して回避する案です。trylock 自体は有効な道具ですが、順序逆転の構造を残したままリトライで回すと、今度は高負荷時のスピン、リトライ嵐、遅延増大として現れることがあります。表面上は EDEADLK が消えても、サービス品質の面では別の問題へ置き換わっただけ、ということが起こりえます。ロック順序最適化の本質は、競合を“隠す”ことではなく、競合の起き方を単純化して予測可能にすることです。その意味で、順序固定、保持時間短縮、外部待機の切り離しは、派手ではなくても再発防止に効きやすい手法です。

また、保守性の観点からは、「なぜこの順で取るのか」をコードコメントか設計メモに残しておくことも重要です。現場では、人が替わるたびにロック規約が暗黙知になりやすく、それが数年後の順序逆転を招きます。ERRORCHECK mutex が EDEADLK を返してくれる間はまだ診断しやすいですが、DEFAULT や実装依存の振る舞いが混ざると、環境差分によって見え方が変わることがあります。仕様表で DEFAULT は他の標準型に対応する場合もあれば、特定条件では未定義に近い挙動もありうるため、明示的に mutex type を選び、ロック規約と合わせて残す方が長期保守では有利です。

この章の結論として、ロック順序の最適化は、大きな作り直しよりも「順序の固定」「保持時間の短縮」「ロック中の外部待機の削減」「再入の明文化」という四つの軸で進めると、最小変更で収束しやすくなります。ただし、共有ストレージ、複数プロセス、ファイルロック、コンテナ、監査要件が絡む案件では、局所修正が別の層へ影響しやすく、一般論だけでは最適解が定まりません。そうした案件では、実装変更の前に影響範囲と順序規約を診断し、導入手順まで含めて整理することが重要です。個別事情が複雑で、社内だけでは判断が割れる場合は、株式会社情報工学研究所のような専門家へ相談し、依頼判断と対策設計を並行して進める方が現実的です。

第6章：直し方で差が出る運用の未来――再発防止と説明責任まで見据えた改善の着地点

Linux の EDEADLK (35) への対応は、単にエラーを消すだけで終わる話ではありません。現場では、障害が出た直後ほど「まず動かしたい」という空気になりやすい一方で、BtoB の業務システムでは「なぜ起きたのか」「再発しないと言えるのか」「次に同じ条件が来たとき、誰がどう判断するのか」まで問われます。とくに、サーバサイド、SRE、情シス、プロダクトマネージャーの立場では、技術的な原因究明だけでなく、社内説明、顧客説明、監査対応、運用ルール更新まで含めて考えなければなりません。そのため、EDEADLK 対策の最終ゴールは“画面上のメッセージを見えなくすること”ではなく、“再発時にも慌てず収束できる運用状態へ持っていくこと”に置く方が、結果として現場負荷を下げやすくなります。

ここで重要なのは、改善の着地点を「コード修正」だけに置かないことです。たとえば、同一スレッド再取得が原因だった場合、修正そのものは比較的小さく済むことがあります。しかし、それだけでは「なぜその再入が入り込んだのか」「今後の保守で同じ形が再び生まれないか」という問いには答えきれません。逆に、複数ロックの順序逆転やファイルロックを含む待機循環が原因だった場合は、コードの一部修正で沈静化したように見えても、運用条件や構成変更で再燃する余地が残ります。したがって、改善の終点では、少なくとも「ロック取得順の規約」「ロック保持中にしてよいこと・避けること」「再入を許す例外条件」「ログで追うべき識別子」の四点を、チーム内で共有可能な形にしておく必要があります。

再発防止という観点では、技術対策と運用対策を分けて考えると整理しやすくなります。技術対策は、ここまで見てきたように、順序固定、保持時間短縮、外部待機の切り離し、再入の明文化が中心です。一方、運用対策は、障害時の初動、ログ保全手順、変更凍結の判断基準、問い合わせのタイミング、関係者への報告フォーマットを定めることが中心になります。現場でつらいのは、障害そのものより「毎回、説明の仕方と判断基準がぶれる」ことです。そこを整えておくと、次に似た事象が起きても、議論の温度を下げやすくなります。

特に BtoB の現場で重視したいのは、「一般論として正しい対策」と「その案件で採れる対策」は必ずしも一致しないという点です。一般論としては、ロック階層の明文化や責務分離の徹底が望ましくても、実際には停止許容時間、契約上の制約、接続先システム、夜間バッチ、共有ストレージ、コンテナの再配置、監査証跡の扱いなどが重なり、動かせる範囲が限られることがあります。そこで無理に理想形へ寄せようとすると、改善そのものが新たな運用リスクになります。反対に、最小変更だけを優先しすぎると、数か月後の改修で同じ論点に戻ることもあります。つまり、本当に必要なのは「今すぐ安全に収束させる線」と「次に同じことを起こしにくくする線」を分けて設計することです。

その判断で迷いやすいのが、次のような案件です。

• 本番停止の許容時間が短く、検証パターンを十分に回せない。
• 共有ストレージやファイルロックを複数の処理系がまたいで使っている。
• アプリケーションロックと外部システム側の排他制御が混在している。
• 担当チームが複数にまたがり、変更責任の所在が分かれやすい。
• 監査・顧客説明・障害報告まで含めて整理しなければならない。

こうした条件がある場合、一般論だけで「この直し方が正解です」と言い切るのは危険です。なぜなら、コード上の正しさと、契約・運用・説明責任を含めた正しさは、しばしば別の判断になるからです。たとえば、あるロック順序変更が理論上は妥当でも、夜間バッチのタイミングやフェイルオーバー手順、監査ログ取得方式との兼ね合いで、そのままは入れられないことがあります。そのようなときに必要なのは、技術だけでなく、導入順、切り戻し条件、影響範囲、代替策まで含めた“案件としての設計”です。

その意味で、このブログの到達点は「自力で全部直し切ること」を勧めることではありません。むしろ、どこから先が一般論の限界なのかを見極め、相談や依頼のタイミングを早めることに価値があります。EDEADLK は、目の前の障害メッセージとしては一つでも、その背後には mutex 属性の選び方、呼び出し責務の重複、ロック順序、ファイルロック方式、共有構成、運用制約が重なっています。ここを社内の限られた時間だけで整理しようとすると、判断の先送りや局所修正の積み重ねになりやすく、結果として現場が疲弊します。だからこそ、ログ保全と初動整理までは社内で進めつつ、その先の影響範囲診断や対策設計は、案件に応じて専門家の視点を入れる方が現実的です。

とくに、次のような場面では、相談を前提に動いた方が収束しやすくなります。

• エラーの意味は見えてきたが、ロック順序変更の波及範囲が読めない。
• データ保全、監査要件、共有ストレージ、外部連携が絡み、単純なコード修正で済まない。
• ロック実装だけでなく、システム構成や運用フローの見直しが必要になっている。
• 社内説明や顧客説明に耐える形で、原因と対策を文書化したい。
• いまの修正で一旦の収束は見えても、将来の再発防止まで視野に入れたい。

こうした案件では、株式会社情報工学研究所のように、設計、保守、障害対応、機密保持、運用現場の制約を踏まえて相談に乗れる相手がいることが大きな意味を持ちます。単なるコードレビューではなく、「この構成なら、どこまでが最小変更か」「どこからは段階的改修にした方が安全か」「先にログ設計を整えるべきか」「問い合わせや依頼の単位をどう切るべきか」といった判断を支援できるからです。一般論の知識だけでは越えにくい壁は、案件の文脈を持ち込んだ時点で初めて整理しやすくなります。

Linux EDEADLK (35) や「Resource deadlock avoided」は、現場にとっては小さなエラー文言ではなく、設計・構成・運用のどこかに歯止めを入れる必要があることを示すサインです。だからこそ、焦って大きく直すのではなく、安全な初動で場を整え、原因を切り分け、影響範囲を見極め、必要なら早めに相談する、という流れが重要になります。個別案件で悩んだときは、問い合わせフォーム https://jouhou.main.jp/?page_id=26983 や電話 0120-838-831 を通じて、株式会社情報工学研究所への相談・依頼を検討してください。現場の負担を増やさずに収束へ向かうためには、一般論を知ること以上に、その案件に合った判断を早く持てることが重要です。

はじめに

Linuxシステムの運用において、リソースのデッドロックは避けて通れない課題の一つです。特に、「EDEADLK (35) Resource deadlock avoided」というエラーは、複数のプロセスが同時にリソースを要求しあう際に発生しやすく、システムの安定性やパフォーマンスに影響を及ぼす可能性があります。このエラーは、システムがリソースの循環的な待ち状態を検知し、デッドロックを未然に防ぐためにリクエストを制御した結果として発生します。システム管理者やIT担当者にとって、原因の理解と適切な対策は、システムの信頼性維持に欠かせません。本記事では、エラーの背景にある仕組みや原因をわかりやすく解説し、現状のシステム環境に合わせたロック順序の最適化方法についても詳しく紹介します。データの安全とシステムの安定運用を支えるために、正確な知識と適切な対応策を身につけることが重要です。

エラーコード「EDEADLK (35)」は、リソースの循環待ち状態を検知したシステムが自動的にデッドロックを回避するためにリクエストを制御した結果として発生します。これは、複数のプロセスやスレッドが互いに必要とするリソースを待ち続ける状態、いわゆるデッドロックに陥るのを防ぐための仕組みです。具体的には、例えば複数のアプリケーションやサービスが同時に同じファイルやデータベースのロックを要求し、互いに相手の解放を待つ状態が続くと、システムはこれを検知し、リクエストの一部を拒否または制御します。こうした制御は、システムの安定性を保つために必要不可欠ですが、その裏側にはリソースの管理と待ち状態の調整という複雑な仕組みが存在します。理解を深めるためには、リソースの種類や管理方法、待ち状態の発生条件を把握することが重要です。これらの要素を理解することで、システムの挙動を予測し、適切な対策を講じることが可能となります。 ※当社は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。

システムのリソース管理とロックの制御は、デッドロックを未然に防ぐための重要なポイントです。リソースの種類には、ファイル、データベースの行やテーブル、メモリの領域などさまざまありますが、どれも複数のプロセスが同時にアクセスしようとする際に競合が生じやすいものです。こうした競合を管理するためには、リソースの獲得順序や解放タイミングを適切に設計することが求められます。 例えば、複数のアプリケーションが同じデータベースにアクセスする場合、各プロセスがリソースを獲得する順序を統一することが効果的です。これにより、循環待ちの状態を防ぎ、デッドロックのリスクを低減できます。また、ロックの粒度を細かく設定し、必要最低限の範囲だけをロックすることも有効です。これにより、待ち時間や競合の頻度を抑えることが可能となります。 さらに、システムの負荷状況に応じて動的にロック戦略を調整する仕組みを導入することも検討できます。例えば、待ち状態が長引く場合には、優先度を見直したり、タイムアウトを設定して一定時間待ち続けることを避けたりする方法です。こうした手法は、システムの安定性を保ちつつ、リソースの効率的な利用を促進します。 これらの管理策を実践することで、リソースの循環待ちを未然に防ぎ、システムの信頼性を向上させることが可能です。システム設計時には、具体的なリソースの特性や利用状況を把握し、最適なロック戦略を策定することが重要です。 ※当社は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。

システムのリソース管理とロックの制御を最適化するためには、具体的な設計と運用の工夫が不可欠です。まず、リソースの獲得順序を統一することが基本となります。複数のプロセスが同じリソースにアクセスする場合、あらかじめ決められた順序でリソースを取得することで、循環待ちの状態を防ぐことが可能です。例えば、複数のアプリケーションが同じデータベースのテーブルや行にアクセスする場合、すべてのプロセスが同じ順序でロックを獲得するように設計します。これにより、相互に待ち状態に陥るリスクが低減されます。 次に、ロックの粒度を細かく設定することも重要です。大きな範囲を一度にロックしてしまうと、待ち時間が長くなりやすく、デッドロックの発生確率も高まります。逆に、必要最小限の範囲だけをロックすることで、他のプロセスの待ち時間を短縮し、システム全体の効率性を向上させます。 さらに、動的なロック管理を導入することも効果的です。システムの負荷や待ち行列の状況に応じて、ロックの優先順位やタイムアウト設定を調整します。たとえば、長時間待ち続けるプロセスに対しては、優先度を下げたり、一定時間経過後に自動的にロックを解放したりする仕組みを設けることで、待ち状態の長期化を防ぎ、システムの安定運用を支えます。 これらの管理策を組み合わせることで、リソースの循環待ちやデッドロックのリスクを最小限に抑え、システムの信頼性を確保できます。システム設計時には、リソースの特性や利用状況を詳細に把握し、最適なロック戦略を策定することが重要です。こうした取り組みは、システムの安定性とパフォーマンス向上に直結し、運用の効率化に寄与します。 ※当社は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。

リソースの獲得順序とロック粒度の最適化は、デッドロック回避において重要な役割を果たします。まず、複数のプロセスやスレッドが同じリソースにアクセスする場合、あらかじめ決められた順序でリソースを取得することが基本です。これにより、循環的な待ち状態を防ぎ、システムの安定性を向上させることができます。例えば、複数のアプリケーションが同じデータベースのテーブルや行にアクセスする際に、すべてのプロセスが同じ順序でロックを獲得する設計を採用すれば、相互の待ち状態を未然に防ぎやすくなります。 また、ロックの粒度を細かく設定することも効果的です。大きな範囲を一度にロックしてしまうと、待ち時間が長引きやすく、結果としてデッドロックのリスクが高まります。逆に、必要最小限の範囲だけをロックすることで、他のプロセスが待つ時間を短縮し、全体のシステム効率を向上させることが可能です。例えば、データベースの行レベルのロックを適用することで、複数の操作が同時に進行しやすくなります。 さらに、負荷状況に応じた動的ロック管理も有効です。システムの状態を監視し、待ち行列やリソース利用率に応じて、優先度やタイムアウト設定を調整します。長時間待ち続けるプロセスには優先度を下げたり、一定時間経過後に自動的にロックを解放したりする仕組みを導入すれば、待ち状態の長期化やデッドロックの発生を抑制できます。 こうした取り組みを組み合わせることで、リソースの循環待ちを未然に防ぎ、システムの信頼性と安定性を高めることが可能です。設計段階からこれらのポイントを意識し、具体的な運用方法を定めることが、データの安全とシステムの継続的な稼働に直結します。

リソースのロック順序と粒度の最適化は、デッドロック回避のための基本的かつ重要な戦略です。まず、複数のプロセスが同じリソースにアクセスする場合、あらかじめ決められた順序でリソースを獲得することが効果的です。これにより、循環的な待ち状態を未然に防ぎ、システムの安定性を向上させることができます。例えば、すべてのプロセスが同じリソース順序を守ることで、互いに待ち状態に陥るリスクを大幅に軽減できます。 次に、ロックの粒度を細かく設定することも重要です。大きな範囲を一度にロックしてしまうと、待ち時間が長引きやすく、結果的にデッドロックの発生確率が高まります。逆に、必要最小限の範囲だけをロックすることで、他のプロセスが待つ時間を短縮し、全体の効率性を向上させることが可能です。例えば、データベースの行レベルのロックを採用すれば、複数の操作が同時に進行しやすくなります。 さらに、システムの負荷や待ち行列の状況に応じて動的にロック戦略を調整する仕組みも有効です。長時間待ち続けるプロセスには、優先度を下げたりタイムアウトを設定したりすることで、待ち状態の長期化やデッドロックのリスクを抑制できます。こうしたアプローチは、システムの安定性とパフォーマンスを維持しながらリソースの効率的な利用を促進します。 これらの管理策を総合的に取り入れることで、リソースの循環待ちやデッドロックを未然に防ぎ、システムの信頼性を確保できます。設計段階からこれらのポイントを意識し、実運用においても継続的に見直すことが、安定したシステム運用の鍵となります。システムの健全性を保つためには、リソース管理の最適化が欠かせません。

本稿では、Linuxシステムにおいて頻繁に直面する「EDEADLK (35) Resource deadlock avoided」エラーの背景と原因について解説しました。このエラーは、複数のプロセスやスレッドがリソースの循環的な待ち状態に陥ることを防ぐためにシステムがリクエストを制御した結果として発生します。原因の理解には、リソース管理の仕組みや待ち状態の発生条件を把握することが不可欠です。さらに、デッドロックを未然に防ぐためには、リソースの獲得順序を統一し、ロックの粒度を細かく設定すること、そして動的な管理を導入することが重要です。これらの管理策を適用することで、システムの安定性と信頼性を高めることが可能です。システム管理者やIT担当者は、これらのポイントを意識しながら運用と設計を見直すことで、リソース競合のリスクを最小限に抑えることができ、安心してシステムを運用できる環境を整えることができるでしょう。

システムの安定運用とデータの安全性を確保するためには、適切なリソース管理とロック制御の理解と実践が欠かせません。今回ご紹介したポイントを参考に、システム設計や運用の見直しを進めてみてはいかがでしょうか。専門的な知識や経験が必要と感じられる場合は、信頼できる技術支援やコンサルティングサービスの活用も検討してください。適切な対策を講じることで、リソース競合やデッドロックのリスクを低減し、システムの信頼性を向上させることが可能です。ご不明な点や具体的な対策についてのご相談は、お気軽にお問い合わせください。私たちの専門チームが、現状のシステム環境に最適な解決策を提案し、長期的な安定運用をサポートいたします。

システムのリソース管理やロック制御に関する対策を講じる際には、いくつかの重要な注意点を押さえておく必要があります。まず、リソース獲得の順序や粒度の最適化を行う際には、システムの実状や利用状況を正確に把握し、それに基づいた設計を心掛けることが大切です。過度に細かい粒度や複雑なロック戦略は、逆にシステムのパフォーマンスを低下させる可能性があります。次に、ロックのタイムアウト設定や優先度調整は効果的ですが、これらを適切に設定しないと、待ち状態の長期化やリソースの無駄遣いにつながる恐れがあります。特に、タイムアウト値の設定にはシステムの負荷や処理時間を考慮し、現実的な範囲内に調整する必要があります。 また、動的なロック管理を導入する場合、システムの負荷変動や待ち行列の状況を正確に監視し、適切に対応できる仕組みを整えることが求められます。これには運用コストや管理負担も伴うため、十分な計画とリソース配分が必要です。さらに、リソースの管理策を実施した後も、定期的な見直しやチューニングを継続しなければ、想定外の状況や新たな問題が発生する可能性があります。最後に、システムの設計や運用においては、セキュリティやデータプライバシーの観点も忘れてはなりません。リソース管理の改善策が、逆にシステムの脆弱性を高めたり、情報漏洩のリスクを増大させたりしないよう注意が必要です。これらのポイントを意識しながら、継続的な改善と適切な管理を行うことが、システムの安定性と安全性を確保するための基本となります。 ※当社は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。

補足情報

※株式会社情報工学研究所は（以下、当社）は、細心の注意を払って当社ウェブサイトに情報を掲載しておりますが、この情報の正確性および完全性を保証するものではありません。当社は予告なしに、当社ウェブサイトに掲載されている情報を変更することがあります。当社およびその関連会社は、お客さまが当社ウェブサイトに含まれる情報もしくは内容をご利用されたことで直接・間接的に生じた損失に関し一切責任を負うものではありません。