やってみた
Sudo apt update
しかし得た:
ロック/ var/lib/apt/lists/lockを取得できませんでした-オープン(11:リソースは一時的に利用不可)
E:ディレクトリ/ var/lib/apt/lists /をロックできません
Mongodの最新バージョンを入手しようとしています。私が見つけたいくつかの指示に従って、私はしました:
$ ps aux | grep apt
5019 0.0 0.0 14224 980 pts/0 S+ 02:52 0:00 grep --color=auto apt
しかし、私はこれのどの部分を差し込むべきか分かりません
kill -9 processnumber <id>
それを動作させるために。
どの部分がIDであり、これが再発しないようにする方法はありますか?
名前または引数リストに基づいてプロセスを強制終了する場合は、pkill
を使用します。
pkill regexp
名前がregexp
拡張正規表現に一致するすべてのプロセスを強制終了します。
pkill -f regexp
引数のリスト(通常はコマンド名を含む最初のリストを含む)がスペースで連結され、正規表現に一致するすべてのプロセスを強制終了します。
ただし、ここでは、/var/lib/apt/lists/lock
ロックファイルを保持しているプロセスを強制終了するように見えます。
fuser -k /var/lib/apt/lists/lock
(一部のフューザー実装を使用)または
lsof -t /var/lib/apt/lists/lock | xargs kill
より適切な場合があります。
どのプロセスが最初にlsof /var/lib/apt/lists/lock
またはfuser /var/lib/apt/lists/lock
であるかを確認することもできます。そして、できればそれを冷やして殺す代わりに、それを普通に終了させてください。
いずれの場合も、プロセスが正常に終了する機会を与えないkill -9
は避けてください。
これは、ps … | grep …
を使用してはならない2つの理由を示しています。
ps
はタイトル行を出力します。ただし、出力はgrep
にパイプされ、grepパターンがタイトル行と一致しないため、タイトル行が表示されません。タイトル行に、PID
という列があります。この列の値は、kill
に渡す必要があるものです。
ps … | grep …
を実行すると、grepプロセス自体がリストされることがよくあります。あなたの場合、あなたはgrepプロセスだけを見ています。 grepプロセスが表示されるかどうかはランダムです。パイプはps
とgrep
を並行して実行し、grep
はps
は実行されますが、ps
が非常に速く実行され、grep
がまだ開始されていない場合があります。パターンがそれ自体と一致しないことを確認するなど、grepプロセスを表示しないようにするトリックがあります。
ps aux | grep '[a]pt'
しかし、これを行うにはより信頼できる方法があります。 Linuxおよびその他のシステムは、 pgrep
と呼ばれるユーティリティを提供します。 ps … | grep …
と少し似ていますが、より確実です。
pgrep apt
プロセスに関する情報を取得するには、プロセスIDをps
に渡します。
ps $(pgrep apt)
それらをすべて強制終了したい場合は、pgrep
コマンドをpkill
に変更できます。それらの一部のみを強制終了する場合は、pgrep
コマンドラインに基準を追加して、必要なプロセスのみに一致するようにするか、ps
出力からPIDを手動で選択します。
Linuxのps
コマンドは、コマンド名を含むいくつかの基準でプロセスを照合することもできますが、完全一致が必要ですが、pgrep
は部分文字列とより一般的には正規表現の一致を見つけることができます。
ps -C apt # won't find e.g. apt-get
ただし、これは、aptロックの問題を解決する最良の方法ではありません。これについては StéphaneChazelasの回答 を参照してください。