Ужасная проблема с fwupd в ubuntu 16.04 [dубликат]
Я обновил свой ноутбук (Lenovo Z50-70), у которого есть процессор i7 и 8Gigs Ram до Ubuntu 16.04 от 15.10. Я постоянно устанавливаю обновления. Я использую ubuntu с рабочей средой Gnome (GDM).
В последнее время у меня возникла странная проблема, мой процессор (включая все 4 ядра) на 100% используется некоторыми процессами, такими как gnome-software ( Gnome) и fwupd (демон обновления прошивки). Это заставляет меня работать. Если я даже убью эти процессы, они снова начнут возвращаться.
Есть ли решение для этих процессов не использовать 100% моего процессора. И мне не нужны ответы, в которых используется утилита cpulimit для обеспечения количества процессоров для этих процессов. Я нахожу это основной проблемой в Ubuntu, я ожидаю реальных решений проблемы.
То, что я пробовал до сих пор, заключается в том, что я удалил эти PPA, кроме официальных PPA для проверки обновлений. Это не сработало! Приложил скриншот экрана htop этих процессов.
17 ответов
Мне удалось решить это, проверив syslog (/var/log/syslog). Он записывался как сумасшедший, что он не мог создать файл /home/<my user>/.cache/dconf/user. Когда я дал этой папке правильные разрешения, она перестала использовать этот большой процессор.
Эта проблема с fwupd случилась со мной сегодня на одном компьютере. У меня также было два экземпляра работы gnome-software. В целом, 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 указал на следующий отчет об ошибке на панели запуска:
Я нашел комментарий 18 особенно интересным:
https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1591868/comments/18
Человек говорит, что проблема не воспроизводима, но если у вас были проблемы с apt-get (как, например, обновление / установка программного обеспечения), из-за этого вполне возможно. И действительно, у меня было несколько файлов в apt-кеше, которые были полным дерьмом (т. Е. Мое подключение к Интернету провалилось пару дней назад, а некоторые из файлов кеша включали ошибку HTTP 302 вместо ожидаемых списков пакетов.) Я нахожу этот конкретный комментарий интересно, потому что ошибка все еще существует, но не из-за файла yaml, как указано там. В моем случае я не мог найти ни одного файла yaml где угодно.
Держу пари, что https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug / 1591868 / comments / 18 , я исправил проблему. Похоже, что код был исправлен некоторое время назад. Мне просто нужно перезагрузить, чтобы подтвердить, что это 100% -ное использование ЦП не повторяется снова.
Может быть случай, когда в syslog ничего не содержится в службе, и в этом случае вы можете просто перезапустить его. Чтобы избежать поиска служб и их уничтожения вручную, вы можете просто использовать systemctl:
sudo systemctl restart fwupd
Была аналогичная проблема.
Как уже упоминалось в другом ответе - можно определить проблему, посмотрев на /var/log/syslog.
В моих настройках gnome журнала сообщалось следующее:
(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
Разрешающая проблема для меня.
смотрит на:
$ cat /var/log/syslog
(gnome-software: 3812): dconf-CRITICAL **: невозможно создать файл '/ home / {user} /. cache / dconf / user ': Permiso denegado. dconf не будет работать должным образом. Выполняя эту команду, проблема решена.
$ sudo chown {user} /home/{user}/.cache/dconf
Такая же проблема со мной, она также блокирует мою систему.
После изменения владельца /home/{user}/.cache/dconf/user это выглядит нормально.
У меня была точно такая же проблема, и в тех же процессах принимал 100% процессора. Я работал над обновлением программного обеспечения в своем Ubuntu (16.04):
sudo apt-get update
sudo apt-get upgrade
После этого я перезагрузил свой компьютер, и теперь проблема исчезла.
Мне удалось решить это, проверив syslog (/var/log/syslog). Он записывался как сумасшедший, что он не мог создать файл /home/<my user>/.cache/dconf/user. Когда я дал этой папке правильные разрешения, она перестала использовать этот большой процессор.
-
1«Правильные разрешения» Было бы неплохо включить, какие разрешения вы дали, и команду, которую вы дали для их назначения. – Andrea Lazzarotto 3 August 2016 в 20:13
-
2
Эта проблема с fwupd случилась со мной сегодня на одном компьютере. У меня также было два экземпляра работы gnome-software. В целом, 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 указал на следующий отчет об ошибке на панели запуска:
Я нашел комментарий 18 особенно интересным:
https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1591868/comments/18
Человек говорит, что проблема не воспроизводима, но если у вас были проблемы с apt-get (как, например, обновление / установка программного обеспечения), из-за этого вполне возможно. И действительно, у меня было несколько файлов в apt-кеше, которые были полным дерьмом (т. Е. Мое подключение к Интернету провалилось пару дней назад, а некоторые из файлов кеша включали ошибку HTTP 302 вместо ожидаемых списков пакетов.) Я нахожу этот конкретный комментарий интересно, потому что ошибка все еще существует, но не из-за файла yaml, как указано там. В моем случае я не мог найти ни одного файла yaml где угодно.
Держу пари, что https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug / 1591868 / comments / 18 , я исправил проблему. Похоже, что код был исправлен некоторое время назад. Мне просто нужно перезагрузить, чтобы подтвердить, что это 100% -ное использование ЦП не повторяется снова.
Может быть случай, когда в syslog ничего не содержится в службе, и в этом случае вы можете просто перезапустить его. Чтобы избежать поиска служб и их уничтожения вручную, вы можете просто использовать systemctl:
sudo systemctl restart fwupd
-
1Это сработало для меня. У меня не было проблем с папкой /home/[user]/.cache, перечисленных выше. – meawoppl 11 March 2018 в 05:27
Была аналогичная проблема.
Как уже упоминалось в другом ответе - можно определить проблему, посмотрев на /var/log/syslog.
В моих настройках gnome журнала сообщалось следующее:
(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
Разрешающая проблема для меня.
смотрит на:
$ cat /var/log/syslog
(gnome-software: 3812): dconf-CRITICAL **: невозможно создать файл '/ home / {user} /. cache / dconf / user ': Permiso denegado. dconf не будет работать должным образом. Выполняя эту команду, проблема решена.
$ sudo chown {user} /home/{user}/.cache/dconf
Такая же проблема со мной, она также блокирует мою систему.
После изменения владельца /home/{user}/.cache/dconf/user это выглядит нормально.
У меня была точно такая же проблема, и в тех же процессах принимал 100% процессора. Я работал над обновлением программного обеспечения в своем Ubuntu (16.04):
sudo apt-get update
sudo apt-get upgrade
После этого я перезагрузил свой компьютер, и теперь проблема исчезла.
Может быть случай, когда в syslog ничего не содержится в службе, и в этом случае вы можете просто перезапустить его. Чтобы избежать поиска служб и их уничтожения вручную, вы можете просто использовать systemctl:
sudo systemctl restart fwupd
Может быть случай, когда в syslog ничего не содержится в службе, и в этом случае вы можете просто перезапустить его. Чтобы избежать поиска служб и их уничтожения вручную, вы можете просто использовать systemctl:
sudo systemctl restart fwupd
Эта проблема с fwupd произошла со мной сегодня на одном компьютере. У меня также было два экземпляра работы gnome-software. В целом, 2 процессора были зажаты на 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. Перед подтверждением убедитесь, что выбран правильный процесс!) [/ g6]
Теперь, @belacqua указал нам на следующий отчет об ошибке на панели запуска:
https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+ bug / 1591868
Я нашел комментарий 18 особенно интересным:
https://bugs.launchpad.net/ubuntu/+source/appstream-glib/ + ошибка / 1591868 / comments / 18
Человек говорит, что проблема не воспроизводима, но если у вас возникли проблемы с apt-get (например, при обновлении / установке программного обеспечения), это может из-за этого очень хорошо. И действительно, у меня было несколько файлов в apt-кеше, которые были полным дерьмом (т. Е. Мое подключение к Интернету провалилось пару дней назад, а некоторые из файлов кеша включали ошибку HTTP 302 вместо ожидаемых списков пакетов.) Я нахожу этот конкретный комментарий интересно, потому что ошибка все еще существует, но не из-за файла yaml, как указано там. В моем случае я не мог найти ни одного файла yaml где угодно.
Готов поспорить, что с помощью исправления кеша apt-get я исправил проблему. Похоже, что код был исправлен некоторое время назад. Мне просто нужна перезагрузка, чтобы подтвердить, что это 100% -ное использование ЦП не происходит снова.