Програмне забезпечення та оновлення споживають 100% процесора в Ubuntu 16.04

Я оновив свій ноутбук (Lenovo Z50-70), який має процесор i7 та 8 Gigs Ram до Ubuntu 16.04 з 15.10. Я постійно встановлюю оновлення. Я використовую ubuntu з середовищем Gnome desktop (GDM).

Останнім часом у мене виникає дивна проблема, мій процесор (включаючи всі 4 ядра) на 100% використовується в таких процесах, як gnome-software(програмне забезпечення Gnome) та fwupd(демон оновлення прошивки). Це змушує мою роботу знижуватися. Якщо я навіть вбиваю ці процеси, вони починаються знову.

Чи є рішення для цих процесів не використовувати 100% мого процесора. І я не хочу, щоб відповіді казали використовувати cpulimitутиліту, щоб забезпечити кількість процесора для цих процесів. Я вважаю це основною проблемою в Ubuntu, я очікую реальних рішень проблеми.

Я намагався поки що - видалення тих PPA, які я додав, крім офіційних PPA для перевірки оновлень. Це не вийшло! Додано скріншот htopекрана цих процесів.

Мав подібне питання.

Як згадується інша відповідь - визначити проблему можна, переглянувши /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

У мене була точно та сама проблема, ті самі процеси, що займають 100% процесора. Для мене працювало оновлення програмного забезпечення в моєму Ubuntu (16.04):

sudo apt-get update
sudo apt-get upgrade

Після цього я перезавантажив свій ПК і тепер проблеми вже немає.

Мені вдалося вирішити це, перевіривши syslog ( /var/log/syslog). Він входив як божевільний, що не міг створити файл /home/<my user>/.cache/dconf/user. Коли я дав цій папці правильні дозволи, вона перестала використовувати цей процессор.

Проблема дозволу для мене.

дивлячись на:

$ cat /var/log/syslog

(gnome-software: 3812): dconf-CRITICAL **: неможливо створити файл '/home/{user}/.cache/dconf/user': Permiso denegado. dconf не працюватиме належним чином.

Виконавши цю команду, проблема була вирішена.

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

Може бути випадок, коли в системі немає нічого, що стосується послуги, і в цьому випадку ви можете просто перезапустити його. Щоб не шукати служби та не вбивати їх вручну, ви можете просто скористатися 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. Перш ніж підтвердити, переконайтесь, що вибрано правильний процес!)

Тепер @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 (як, наприклад, оновлення / установка програмного забезпечення), то це може бути через це. І справді, у мене в кеш-програві траплялося декілька файлів, які були загалом (тобто моє підключення до Інтернету не вдалося пару днів тому. Деякі файли кешу включали помилку HTTP 302 замість очікуваних списків пакетів.) Я знаходжу цей конкретний коментар цікаво тим, що помилка все ще є, але не через файл yaml, як зазначено там. У моєму випадку я ніде не міг знайти жодного файлу yaml.

Б'юсь у заклад, що, виправляючи apt-getкеш , я вирішив проблему. Схоже, код уже зафіксований назад. Мені просто потрібна перезавантаження, щоб підтвердити, що це 100% використання процесора більше не відбувається.

Та сама проблема зі мною, що також блокує мою систему.

Після зміни власника /home/{user}/.cache/dconf/userце виглядає нормально.