テクノロジー · 実用ガイド
「Too many levels of symbolic links」？パスを変える前にループ箇所を特定する
循環と40回超の深い連鎖を分け、各コンポーネントと所有元を確認し、誤ったリンクだけを交換します。
Linux は一度のパス解決でシンボリックリンクの上限を超えると ELOOP、つまり「Too many levels of symbolic links」を返します。直接・間接の循環だけでなく、循環なしで40回を超える連鎖も原因です。エラーだけでは最初の誤りは分かりません。
実際の呼び出し元、作業ディレクトリ、未解決のパスを保存します。対象を削除せず、各リンク文字列、最初の重複または過深、生成元を確認し、ロールバックと終了試験付きで一箇所だけ変更します。
呼び出し元と失敗パスを固定する
失敗コマンド、エラー、cwd、実効ユーザー、host/container、root/chroot、渡されたパスをそのまま保存します。相対形と絶対形を分け、手作業の展開で置き換えません。
shell、web server、service、package hook、deploy のどこで失敗したか記録します。同じ文字列でも開始ディレクトリや mount namespace が異なり、管理者の成功は再現を意味しません。
盲目的に追跡せず各要素を見る
同じ view で namei -l -- "$path" などを使い、directory、link、保存 target を順に記録します。個別リンクには lstat、ls -ld、readlink -- を使い、リンク自体を見ます。
readlink -f だけを最初の証拠にしません。失敗箇所が見えないことがあります。相対 target はリンクの所在ディレクトリから評価されます。
循環、過深、別の境界を証明する
trace で最初に繰り返すリンクを印します。自己参照や以前のリンクへ戻るものが循環です。重複がなければ回数を数え、40回超の非循環連鎖も ELOOP になります。
ELOOP を ENOENT、ENOTDIR、EACCES と分けます。欠落、途中の非directory、検索権限不足は、application が同じ一般エラーにしていても別修復です。
交換前に所有元を確認する
package、configuration manager、framework command、container image、release switch、手作業のどれが管理するか確認し、inode、時刻、target と deployment 証拠を保存します。生成元を直さないリンクは再発します。
候補 target が失敗元と同じ root と mount namespace に存在し、型も正しいか確認します。tree 全体の chmod、target directory の削除、全 relative link の absolute 化は避けます。
一箇所を交換して終了試験する
同じ directory に新名で正しいリンクを作り、raw target を検証し、所有する deployment 手順で rename します。旧 target 文字列と rollback を保存し、release 書き込み中なら止めます。
同じ user、cwd、root、namespace で namei と元操作を再実行します。意図した object で終端し、操作が通り、次回 deploy でも修正が残ることを確認します。
