最近、次のエラーが発生したときに、Ubuntuでaptコマンドを使用してアプリケーションをインストールしようとしました：
E：ロックを取得できませんでした/ var / lib / dpkg / lock –オープン（11：リソースが一時的に利用できません）
E：管理ディレクトリ（/ var / lib / dpkg /）をロックできません。別のプロセスがそれを使用していますか？
実際、同様のエラーが表示される場合があります：
E：ロックを取得できませんでした/ var / lib / apt / lists / lock –オープン（11：リソースが一時的に利用できません）
E：ディレクトリ/ var / lib / apt /lists/をロックできません
E：ロックを取得できませんでした/ var / lib / dpkg / lock –オープン（11：リソースが一時的に利用できません）
E：管理ディレクトリ（/ var / lib / dpkg /）をロックできません。別のプロセスがそれを使用していますか？
場合によっては、SoftwareCenterの使用中に表示されることがあります。
これらのエラーは、別の一般的なUbuntuエラーであるディレクトリ/ var / cache / apt / archives /をロックできませんと非常によく似ています。興味深いのは、修正も同様であるということです。
「管理ディレクトリ（/ var / lib / dpkg /）をロックできません」エラーの修正
他のプログラムがUbuntuを更新しようとしているため、このエラーが表示されます。コマンドまたはアプリケーションがシステムを更新しているとき、または新しいソフトウェアをインストールしているとき、dpkgファイル（Debianパッケージマネージャー）をロックします。
このロックは、2つのプロセスが同時にコンテンツを変更しないようにするために行われます。これは、不当な状況やシステムの破損につながる可能性があるためです。
「管理ディレクトリをロックできない」というこの問題を修正するために実行できる手順を見てみましょう。
方法0：
最初にすべきことは、他のプログラムがシステムアップデートを実行しているか、プログラムをインストールしているかどうかを確認することです。
コマンドラインを使用している場合は、Software Center、Software Updater、Synapticパッケージマネージャー、Gdebiなどのアプリケーションが更新/インストールを実行しているかどうかを確認してください。その場合は、プログラムが実行中のプロセスを終了するまでお待ちください。
そのようなアプリケーションが実行されていない場合は、開いているすべてのターミナルウィンドウをチェックして、アップデートを実行しているか、プログラムをインストールしているかを確認してください。はいの場合は、終了するのを待ちます。
上記のいずれも発生しない場合は、aptコマンド（ソフトウェアを処理するためのパッケージマネージャー）を実行している他のプロセスを確認してください。次のコマンドを使用します：
ps aux | grep -i apt私にとって、それはこの出力を示しました：
[email protected]:~$ ps aux | grep -i apt
root 1464 0.0 0.0 4624 772 ? Ss 19:08 0:00 /bin/sh /usr/lib/apt/apt.systemd.daily update
root 1484 0.0 0.0 4624 1676 ? S 19:08 0:00 /bin/sh /usr/lib/apt/apt.systemd.daily lock_is_held update
_apt 2836 0.8 0.1 96912 9432 ? S 19:09 0:03 /usr/lib/apt/methods/http
abhishek 6172 0.0 0.0 21532 1152 pts/1 S+ 19:16 0:00 grep --color=auto -i apt
aptがapt.systemd.daily updateなどのプログラムで使用されていることがわかった場合 、あなたは幸運です、私の愛する読者。
これはバックグラウンドで実行されるデーモンであり、システムの起動時にシステムの更新を自動的にチェックします。
Ubuntu 18.04以降のバージョンでは、重要なセキュリティ更新プログラムを独自にダウンロードしてインストールしようとする場合もあります。少なくともこれは、Ubuntuデスクトップのソフトウェアとアップデートツールのデフォルト設定に表示されるものです。
Ubuntuサーバーを使用している場合は、ファイルの内容を確認することで、無人アップグレードが有効になっているかどうかを確認できます /etc/apt/apt.conf.d/20auto-upgrades 。
したがって、apt.systemd.dailyがaptプロセスを使用している場合は、数分待つだけです。自動更新が終了すると、通常どおりソフトウェアをインストールできるようになります。
恒久的な解決策として、自動更新と無人アップグレードのチェックを完全に無効にすることができますが、セキュリティ上の理由からそのことはお勧めしません。
さて、それは単純なシナリオであり、簡単に処理できました。しかし、それが常に当てはまるとは限りません。他のプログラムがaptを使用している場合は、別の方法で処理する必要があります。
方法1：
Linuxコマンドラインを使用して、実行中のプロセスを見つけて強制終了します。これを行うには、以下のコマンドを使用します：
ps aux | grep -i aptこれにより、aptまたはapt-getを実行しているプロセスのIDが表示されます。以下の例では、プロセスIDは7343です。「grep–color=auto」を含む最後の行は無視してかまいません。
プロセスIDを使用して、SIGTERMシグナルを送信することでプロセスIDを終了できます。
sudo kill <process_id>「psaux|」を実行して、プロセスが強制終了されたかどうかを確認します。 grep -i apt’コマンド。それがまだ実行されている場合は、SIGKILLシグナルで強制的に強制終了します：
sudo kill -9 <process_id>もう1つの簡単な方法は、killallコマンドを使用することです。これにより、実行中のプログラムのすべてのインスタンスが強制終了されます：
sudo killall apt apt-get方法2
上記の方法で問題が解決する場合がほとんどです。しかし、私の場合は少し異なっていました。システムを更新していて、誤ってターミナルを閉じてしまいました。そのため、aptを実行しているプロセスはありませんでしたが、それでもエラーが表示されました。
上記の2つの方法を試すか、最初にシステムを再起動することをお勧めします。それでもうまくいかない場合は、ロックファイルを削除するこのオプションを選択するのはあなただけです。
この場合、根本的な原因はロックファイルです。前述のように、ロックファイルは、2つ以上のプロセスが同じデータを使用するのを防ぐために使用されます。 aptまたはapt-getコマンドを実行すると、いくつかの場所にロックファイルが作成されます。前のaptコマンドが適切に終了しなかった場合、ロックファイルは削除されないため、apt-getまたはaptコマンドの新しいインスタンスが阻止されます。
この問題を解決するには、ロックファイルを削除するだけです。ただし、その前に、ロックファイルを使用しているプロセスをすべて停止することをお勧めします。
lsofコマンドを使用して、ロックファイルを保持しているプロセスのプロセスIDを取得します。エラーをチェックして、エラーが発生しているロックファイルを確認し、これらのロックファイルを保持しているプロセスのIDを取得します。
これらのコマンドを1つずつ実行します。
sudo lsof /var/lib/dpkg/lock
sudo lsof /var/lib/apt/lists/lock
sudo lsof /var/cache/apt/archives/lock
コマンドが何も返さないか、1つの数値だけを返す可能性があります。少なくとも1つの数値が返される場合は、その数値を使用して、次のようにプロセスを強制終了します（
sudo kill -9 <process_id>以下のコマンドを使用して、ロックファイルを安全に削除できるようになりました。
sudo rm /var/lib/apt/lists/lock
sudo rm /var/cache/apt/archives/lock
sudo rm /var/lib/dpkg/lockその後、パッケージを再構成します。
sudo dpkg --configure -aこれで、sudo apt updateコマンドを実行すると、すべてが正常になります。
トラブルシューティング1：「dpkgフロントエンドロックを取得できません」
次のようなエラーが表示された場合：
[email protected]:~$ sudo apt install grub-customizer
E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource temporarily unavailable)
E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?前のセクションで説明したように、lsofコマンドを使用して、どのプロセスがロックフロントエンドを保持しているかを確認する必要があります。
sudo lsof /var/lib/dpkg/lock-frontendこれは私に見せたものです：
[email protected]:~$ sudo lsof /var/lib/dpkg/lock-frontend
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
unattende 2823 root 5uW REG 8,2 0 145221 /var/lib/dpkg/lock-frontend「無人」が表示された場合 ‘COMMAND列、これは無人のセキュリティアップグレードが実行されていることを意味します。 プロセスが完了するのを待つ必要があります 。基本的に、これは私が方法0で説明したことですが、おそらくそれをスキップしました。
コマンドが別のものである場合は、プロセスを強制終了してから、ロックファイルを削除できます。 PID列の下にプロセスIDが表示されます。このPIDを使用して、プロセスを強制終了します。その後、ロックファイルを削除し、updateコマンドを実行して、修正されているかどうかを確認します。
sudo kill -9 PID
sudo rm /var/lib/dpkg/lock-frontend
sudo apt updateそのlsofとは何ですか：警告はstat（）fuse.gvfsd-fuseファイルシステムを使用できませんか？
注：「lsof：warning ca n’t stat（）fuse.gvfsd-fuse file system / run / user / 1000 / gvfs
前述のlsofコマンドを実行した後、出力情報が不完全である可能性があります。慌てる必要はありません。
それはエラーではありません。 lsofがマウントされたファイルシステムも調べようとしているだけで、警告はそれらのマウントされたシステムに関するものです。
ファイルはメインファイルシステムのプロセスによってロックされているため、警告が表示されて出力がない場合は、それらのロックファイルを使用しているプロセスがないことを意味するだけです。
トラブルシューティング2：「dpkg：エラー：dpkgフロントエンドが別のプロセスによってロックされています」
方法2のステップの実行中に「dpkgフロントエンドが別のプロセスによってロックされています」というエラーが表示された場合は、さらに1つのステップを実行する必要があります。
まず、ロックファイルを保持しているプロセスのIDを見つけます。
sudo lsof /var/lib/dpkg/lock-frontend上記のコマンドは、ロックファイルを使用するプロセスの詳細を提供します。プロセスIDを使用して、このプログラムを強制終了します：
sudo kill -9 PIDこれで、ロックを解除してdpkgを再構成できます：
sudo rm /var/lib/dpkg/lock-frontend
sudo dpkg --configure -aそれはあなたのために働きましたか？どの方法で修正されましたか？
この小さなヒントが、「ロックを取得できませんでした/ var / lib / dpkg/lock」エラーの修正に役立つことを願っています。はいの場合は、コメントでどの方法が効果的かをお知らせください。
それでも問題が発生する場合は、お知らせください。お手伝いさせていただきます。
他の提案もコメントで歓迎します。