Ubuntuでの「/var/lib/dpkg/」ロックできないエラーの理由と解決策
コマンドラインからパッケージをインストール/更新する際に(apt-getまたはaptを使用)、このエラーが発生することがよくあります:E: 管理ディレクトリ(/var/lib/dpkg/)をロックできません。初心者の観点から見ると、これは複雑なエラーです。新しいユーザーは通常、「/var/lib/dpkg/」ディレクトリと、現在実行している操作との関連性について知らないからです。
技術的には、このエラーはシステムによって複数のシナリオで発生し、問題を解決する方法に注意を払う必要があります。この記事では、このエラーに関連するすべての側面と、それを安全に解決する方法について説明します。
ロックできない(/var/lib/dpkg/)– 問題の診断
このエラーに遭遇した場合、最初のステップはエラーの説明を注意深く読むことです。通常、いくつかの重要で時間を節約できるヒントが含まれています。例えば、以下のスクリーンショットは「apt-get install」コマンドが似たようなエラーを投げる様子を示しています。


しかし、よく見ると、最初の行の括弧内のテキストと、2行目のカンマの後のテキストは両方のシナリオで異なっており、最初のシナリオのエラーはユーザー権限に関連していることが明らかです。一方、2番目のシナリオはロックファイルが一時的に利用できないことに関連しています。
もし、上記の最初の画像に示されているような権限関連のエラーに直面している場合、それは「apt-get」または「apt」コマンドを実行しているユーザーに十分な権限がないためであり、コマンドがsudoなしで実行された可能性が高いです。コマンドをルート権限で実行すると、エラーは解消されます。
しかし、ロック関連のエラーの場合は、さらなる調査が必要です。
関連記事: Ubuntuでの「ユーザー名はsudoersファイルにありません。このインシデントは報告されます」エラーの修正
/var/lib/dpkg/とは?
「/var/lib/dpkg/」は、パッケージマネージャー「dpkg」の作業ディレクトリと考えることができ、実際には「apt-get」(および「apt」や「aptitude」ツール)の背後にあるエンジンです。これらのツールを使用してソフトウェアをインストールまたは削除する際、実際の操作を行う前にパッケージデータベースをロックします(「ロック」ファイルを作成することによって)。これは「/var/lib/dpkg/」ディレクトリのロックを取得することによって実行されます。このステップは、データの破損や他のプロセスによって実行されている進行中の操作の中断を避けるのに役立ちます。
上記の概念を理解したと仮定して、次に調査手順について説明します。
ステップ1: ロックを保持している他のプロセスがあるか確認する
これは今やかなり論理的に思えるでしょう?これを行うには、古き良きpsコマンドの助けを借りて、その出力をgrepコマンドにパイプして、探しているものを見つけるのにかかる時間を短縮できます。例えば、以下のコマンドは、すでに実行中の「apt」、「apt-get」、または「aptitude」プロセスがあるかどうかを確認することができます:
ps aux |grep aptステップ2: しばらく待ってからアクションを取る
実際にロックを取得しているコマンドがある場合、理想的にはそれが完了してロックを解放するのを待つべきです。しかし、コマンドが予想以上の時間を要しており、どこかでスタックしていると確信している場合は、利用可能なkillまたはkillallコマンドを使用してそれを終了させることができます(詳細はこちら)。これで直面している問題が解決するはずです。
ここで言及する価値があるのは、「dpkg」プロセスを直接終了させることは決して推奨されないということです。これはパッケージデータベースを破損させる可能性があります。この点を強調するのは、今や「apt」や「apt-get」などのツールが内部で「dpkg」を呼び出すことを知っているからです。したがって、「ps」コマンドの出力で「dpkg」プロセスを見つけた場合、それを終了させることを考えるかもしれません。
「apt」、「apt-get」または「aptitude」コマンドを実行して開始されたプロセスを終了させることは、一般的にはるかに安全です。
ステップ3: 「ps」コマンドの出力が役に立たない場合
コマンドラインツールの「apt」や「apt-get」以外にも、ソフトウェアセンターやアップデートマネージャーなどのGUIベースのアプリケーションもこのロックを取得します。
注意: Ubuntuにブートした直後にロック関連のエラーが発生している場合、あなたの操作がアップデートマネージャーによって開始された自動ポーリングと重なっている可能性があります。この場合、少し待つことで問題が解決するはずです。
話を戻すと、GUIベースのアプリケーションについて、もう一つの便利で時間を節約できるオプションはfuserコマンドを使用することです。
「fuser」を使用すると、アクセスされているファイル(この場合は「/var/lib/dpkg/lock」)を知っているだけで、そのファイルにアクセスしているプロセスを終了させることができます。たとえば:
sudofuser-cuk/var/lib/dpkg/lockfuserコマンドは、あなたが終了させたプロセスによって取得されたロックを解放しないので、手動でこれを行う必要があります:
sudorm-f/var/lib/dpkg/lock注意: 「ロックを解放する」とは、他のプロセスが「ロックを取得する」ために再作成できるように「ロック」ファイルを削除することを意味します。
次の2つのコマンドを実行する必要があるかもしれません:
sudofuser-cuk/var/cache/apt/archives/lock; sudorm-f/var/cache/apt/archives/lock重要なヒント: 最初のステップとしてロックファイルを削除することは決してしないでください – これは最後の手段としてのみ行うべきです。
結論
一般的に、問題を解決する前にその背後にある理由を理解することは常に良いことです。問題を解決するために盲目的に解決策を試みることは決して役立ちません – いくつかのケースでは成功するかもしれませんが、より多くの場合、特にLinuxのOSでは、さらに大きな混乱に陥ることになります。
ここで議論したエラーに直面したことがありますか?どのように解決しましたか?コメントにあなたの答えを残してください。
関連記事: 「リポジトリにリリースファイルがありません」エラーの修正方法