I7 CPUと8GigのRamを搭載したラップトップ(Lenovo Z50-70)を15.10。からUbuntu 16.04にアップグレードしました。更新プログラムを一貫してインストールしています。 Gnomeデスクトップ環境(GDM)でUbuntuを使用しています。
最近、奇妙な問題が発生しています。CPU(4コアすべてを含む)は、gnome-software
(Gnomeソフトウェア)やfwupd
(ファームウェア更新デーモン)などの一部のプロセスで100%使用されています。これは私の仕事がダウンします。それらのプロセスを強制終了しても、それらは再び開始されます。
CPUを100%使用しないこれらのプロセスの解決策はありますか。また、cpulimit
ユーティリティを使用してこれらのプロセスのCPU量をプロビジョニングするという回答は必要ありません。これはUbuntuの中心的な問題であり、問題の本当の解決策を期待しています。
これまで試したのは、更新を確認するための公式PPAを除き、追加したPPAを削除することです。それはうまくいきませんでした!これらのプロセスのhtop
画面のスクリーンショットを添付しました。
同様の問題がありました。
他の答えが言及したように-/var/log/syslog
を見ることで問題を特定することが可能です。
私のログでは、gnome-settingsは以下を報告していました。
(gnome-settings-daemon:3584): dconf-CRITICAL **: unable to create file '/home/USER/.cache/dconf/user': Permission denied.
これを修正するには、次のコマンドを実行し、USERをユーザー名に置き換えます。
Sudo chown USER /home/USER/.cache/dconf
私はまったく同じ問題を抱えていました。同じプロセスでCPUを100%使用していました。私のために働いたのは、Ubuntu(16.04)のソフトウェアをアップグレードすることでした:
Sudo apt-get update
Sudo apt-get upgrade
その後、私はリブート私のPCになり、問題はなくなりました。
Syslog(/var/log/syslog
)をチェックすることで解決できました。ファイル/home/<my user>/.cache/dconf/user
を作成できなかったのは夢中になってログに記録されていました。このフォルダーに適切なアクセス許可を与えると、これだけのCPUの使用が停止しました。
Syslogにサービスに関連するものが何もない場合があります。その場合、単純に再起動することができます。サービスを検索して手動で強制終了しないようにするには、systemctl
を使用します。
Sudo systemctl restart fwupd
私の許可問題。
見つめている:
$ cat /var/log/syslog
(gnome-software:3812):dconf-CRITICAL **:ファイル '/home/{user}/.cache/dconf/user'を作成できません:Permiso denegado。 dconfは正しく機能しません。
このコマンドを実行すると、問題は解決しました。
$ Sudo chown {user} /home/{user}/.cache/dconf
このfwupd
の問題は、今日1台のコンピューターで発生しました。また、gnome-software
の2つのインスタンスが実行されていました。全体で、2つのCPUが100%にクランプされました。
その騒乱を素早く止めるために、これらの3つのプロセスを強制終了することができます。
ps -ef | less
(find processes in the list, record their PID)
kill <pid1>
kill <pid2>
kill <pid3>
...
(killall gnome-software
とkillall fwupd
を試すこともできますが、killall
コマンドは危険です...そうでなければ、htop
でF9を使用できます。確認する前に、確認してください正しいプロセスが選択されました!)
さて、 @ belacqua は、ランチパッドに関する次のバグレポートを指摘してくれました。
https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1591868
コメント18は特に興味深いものでした。
https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1591868/comments/18
その人は、問題は再現できないと言っていますが、apt-getで問題が発生した場合(ソフトウェアの更新/インストールなど)、それが原因である可能性があります。実際、aptキャッシュにはいくつかのファイルがありました(つまり、数日前にインターネットに接続できず、一部のキャッシュファイルには、予想されるパッケージリストではなくHTTP 302エラーが含まれていました)。興味深いのはバグがまだ存在するからですが、そこに指定されているyamlファイルが原因ではありません。私の場合、どこにもyamlファイルが見つかりませんでした。
apt-get
キャッシュの修正 で間違いないと思いますが、問題を修正しました。しばらく前にコードが修正されたようです。この100%のCPU使用率が再び発生しないことを確認するには、再起動する必要があります。
私と同じ問題、それはまた私のシステムをブロックします。
/home/{user}/.cache/dconf/user
の所有者を変更すると、正常に見えます。