软件和更新程序在Ubuntu 16.04中消耗100％的CPU

我从15.10升级了我的笔记本电脑（联想Z50-70），它有一个i7 CPU和8Gigs的Ram到Ubuntu 16.04。 我一直在安装更新。 我正在使用ubuntu和Gnome桌面环境（GDM）。

最近我遇到了一个奇怪的问题，我的CPU（包括所有4个内核）100％被一些进程使用，如gnome-software （Gnome软件）和fwupd （固件更新守护进程）。 这使我的工作失败了。 如果我甚至杀死这些进程，他们又会重新开始。

有没有一个解决方案，这些过程不使用我的100％的CPU。 我不希望答案说使用cpulimit实用程序为这些进程配置CPU数量。 我发现这是Ubuntu的一个核心问题，我期待这个问题的真正解决方案。

我到目前为止所尝试的是，除了用于检查更新的官方PPA之外，删除了我添加的那些PPA。 那没有用！ 附上了这些流程的htop屏幕截图。

Answer 1

有一个类似的问题。

正如提到的另一个答案 – 可以通过查看/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 

Answer 2

我设法通过检查syslog（ /var/log/syslog ）来解决它。 它疯狂地记录它无法创建文件/home//.cache/dconf/user 。 当我给这个文件夹正确的权限时，它停止使用这么多的CPU。

Answer 3

我有完全相同的问题，相同的进程占用了100％的CPU。 对我有用的是在我的Ubuntu（16.04）中升级软件：

 sudo apt-get update sudo apt-get upgrade 

之后我重启了我的电脑，现在问题就消失了。

Answer 4

我的权限问题。

看着：

 $ cat /var/log/syslog 

（gnome-software：3812）：dconf-CRITICAL **：无法创建文件’/home/{user}/.cache/dconf/user’：Permiso denegado。 dconf无法正常工作。

执行此命令后问题解决了。

 $ sudo chown {user} /home/{user}/.cache/dconf 

Answer 5

可能存在syslog中与服务无关的任何情况，在这种情况下，您可能只想重新启动它。 要避免查找服务并手动systemctl它们，您只需使用systemctl ：

 sudo systemctl restart fwupd 

Answer 6

fwupd这个问题今天发生在我的计算机上。 我还有两个运行gnome-software实例。 总之，2个CPU被钳制在100％。

为了快速阻止这种混乱，我可以杀死这3个进程：

 ps -ef | less (find processes in the list, record their PID) kill  kill  kill  ... 

（您也可以尝试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缓存中有几个文件是完全废话（即几天前我的Internet连接失败，一些缓存文件包含HTTP 302错误而不是预期的包列表。）我发现这个特定的评论有趣的是因为一个bug仍然存在，但不是由于那里指定的yaml文件。 就我而言，我无法在任何地方找到任何yaml文件。

我敢打赌通过修复apt-get缓存 ，我解决了这个问题。 看起来代码已经修复了一段时间了。 我只需要重新启动即可确认此次100％CPU使用率不会再次发生。

Answer 7

同样的问题，它也阻止了我的系统。

更改/home/{user}/.cache/dconf/user所有者后，看起来很正常。