Linuxのシンボリックリンクは素晴らしい機能ですが、壊れてあらゆるものを指し示してしまうことがあります。ここでは、壊れたシンボリックリンクを見つけ、それをチェックし、必要であればシステムから削除する方法を紹介します。

シンボリックリンク 101

シンボリックリンクは、「ソフトリンク」「シンボリックリンク」とも呼ばれ、ファイルやディレクトリを指し示すショートカットのことです。シンボリックリンクは、ファイルマネージャのウィンドウ上では通常のファイルやディレクトリと同じように見えます。また、ターミナルウィンドウのファイル一覧の項目として表示されます。シンボリックリンクが指すファイルやディレクトリは、ファイルシステムのツリー上のどこにでも配置することができます。

例えば、ホームディレクトリに「dave link」というシンボリックリンクがあり、「text」というファイルを指しているとします - file.txt はファイルシステムのツリーの別の場所にあります。シンボリックリンク上で使用されるコマンドは、それが指すファイルにも自動的に適用されます。シンボリックリンク上でcatやlessを使おうとすると、実際には「text」-「file.txt」ファイルの内容が表示されます。

標準的なLinuxのインストールには、多くのシンボリックリンクが含まれています。自分で作成したものでなくても、オペレーティングシステムはそれらを使用します。アプリケーションのインストールルーチンは、通常、実行ファイルを指すためにシンボリックリンクを使用します。ソフトウェアが更新されると、バイナリは新しいバージョンに置き換えられ、新しいファイル名が古いものと同じである限り、すべてのシンボリックリンクが機能し続けます。

ルートディレクトリでlsを使うことで、シンボリックリンクの一部を簡単に確認することができます。いくつかのエントリは、私たちのubuntu 20.10テストマシンで別の色で表示され、それらは水色で表示されています。

以下のように入力します。

ls /

l (longlisting)オプションでより深く掘り下げることができる。以下のコマンドを入力すると、すべての「lib」エントリーと個々の「bin」エントリーが表示されます。

ls -l /lib* /bin

各行の先頭にある "l "は、その項目がシンボリックリンクであることを示しています。の後のテキストは、シンボリックリンクが何を指しているかを示しています。この例では、すべてのディレクトリを対象としています。

オーナー、グループ、その他のパーミッションは、読み取り、書き込み、実行の順に表示されます。これらは、デフォルトではダミーエントリです。シンボリックリンクが指し示すオブジェクトの実際のパーミッションは反映されません。対象ファイルやディレクトリのパーミッションは、ファイルシステムから付与されるものが優先されます。

切断されたシンボリックリンク

シンボリックリンクは、参照するファイルが削除されたり、別の場所に移動したりすると、リンクが切れる（ハングする）。アプリケーションのアンロードルーチンが正しく動作しなかったり、完了する前に中断された場合、壊れたシンボリックリンクが残されることがあります。

シンボリックリンクがファイルを指していることを知らずに誰かが手動でファイルを削除した場合、これらのシンボリックリンクは機能しなくなります。ブルドーザーで破壊された町を示す道路標識のようなものです。

この動作は、カレントディレクトリにある「hello」という名前のシンボリックリンクを使えば簡単に確認できます。次のように入力し、lsで確認します。

ls -l

シンボリックリンクを「実行」すると、「bin」というディレクトリにある「htg」というプログラムが実行されます。

./hello

これで、プログラムを直接実行して、この現象が起こったかどうかを確認することができます。

../bin/htg

予想通り、同じ回答が返ってきました。 プログラムファイルを削除してください。

rm ../bin/htg

さて、シンボリックリンクを見ると、Linuxはそれが破損していることを知っているので、赤で表示されています。また、ファイルを置き換えたり、プログラムを再コンパイルしたり、シンボリックリンクを修正するのに必要なあらゆることを行えるように、以前の状態を教えてくれます。

symlinkを実行しようとすると、得られるエラー参照はsymlink名であり、symlinkが指し示すプログラム名ではないことに注意してください。

以下のように入力します。

./hello

壊れたシンボリックリンクの検索

最近のほとんどのfindにはxtype（拡張タイプ）オプションがあり、壊れたシンボリックリンクを見つけるプロセスを簡略化することができます。ここでは、xtypeにlフラグを付けて、リンクの検索を指示することにします。findとxtypeを次のように使い、他の型フラグを付けずに、xtypeがリンク切れを返すように強制します。

find . -xtype l

このコマンドをテストのホームディレクトリで実行すると、壊れたシンボリックリンクがいくつも見つかります。なお、デフォルトでは再帰的に検索されるため、すべてのサブディレクトリが自動的に検索されます。

予想通り、意図的に壊した「hello」マークが並んでいます。もう一つのシンボリックリンクはFirefoxブラウザに、残りはsnapに関連付けられます。

wcに-l (lines)オプションで出力を渡すと、行数を数えることができ、これは壊れたシンボリックリンクを数えるのと同じである。

以下のように入力します。

find . -xtype l | wc -l

24個のシンボリックリンクが壊れており、意味がないと言われたのです。

検索、レビュー、そして削除

パンチインして壊れたシンボリックリンクをすべて削除する前に、findコマンドの結果をチェックして、壊れたシンボリックリンクに何か正当な理由があるかどうかを確認します。

対象ファイルではなく、シンボリックリンクが問題である場合もあります。シンボリックリンクが正しく作成されていない場合、何も指していないのに、本当のターゲットがそこにあることがあります。この場合、シンボリックリンクの再作成が解決策となります。

また、明らかに壊れたシンボリックリンクが、ファイルロックインジケータやその他の go/no-go インジケータなど、他のものとして使われている可能性もあります。 Firefox はこれを行います; これは私たちのリストの中で最初のシンボリックリンクです。ただし、テスト機ではFirefoxを使用していないため、削除しても問題ありません。

また、ターゲットが定期的にしか現れないということもあり得ますが、これは特定のソフトウェアの予想される（そして望ましい）動作です。他のマシンやクラウドから目的のファイルがコピーされ、その機能を実行した後、再び削除され、次のサイクルで別のプログラムに置き換わるということがあり得ます。

この場合、シンボリックリンクを削除するのではなく、手動で修復するか、インストールを繰り返す必要があります。

保存する必要のあるリンク切れを修正した後、コマンドを繰り返して検索を実行する。すると、検索結果に固定されたシンボリックリンクがないはずである。

セキュリティ上の理由から、シンボリックリンクの削除は自分自身のディレクトリに限定した方が良いでしょう。

壊れたシンボリックリンクを削除する

exec（実行）オプションは、検索結果を見つけるためのコマンドを実行します。rmを使って、壊れたシンボリックリンクを一つ一つ削除していきます。findが壊れた各シンボリックリンクを見つけると、{}文字列は壊れた各シンボリックリンクの名前に置き換えられます。

execに実行させたいコマンドのリストを終了させるには、セミコロン(;)を使用しなければなりません。ここでは、バックスラッシュ（ \ ）を使用してセミコロンを「エスケープ」することで、セミコロンをBashが実行すべき動作としてではなく、findコマンドの一部として扱います。

以下のように入力します。

find . -xtype l -exec rm {} \;

コマンドプロンプトに戻っても、何かが起こったという表示がない。リンク切れが解消されたことを確認するために、以下のように、リンク切れを見つけるコマンドを繰り返す。

find . -xtype l

一致するものがないため、壊れたシンボリックリンクが削除されたことを意味します。

最初に復習することを忘れない

繰り返しになりますが、シンボリックリンクを削除するコマンドを実行する前に、必ずシンボリックリンクのリストを確認する時間を取ってください。適当なディレクトリにある不明なものを削除するコマンドを実行することで、削除を回避することができます。

例えば上記では、「.snap」ディレクトリでコマンドを実行し、個々の「hello」シンボリックリンクを手動で削除することができました。これにより、Firefoxのロックシンボルリンクはそのまま残ります。