Oprogramowanie i narzędzie do aktualizacji zużywa 100% procesora w Ubuntu 16.04

Zaktualizowałem mojego laptopa (Lenovo Z50-70), który ma procesor i7 i 8 GB pamięci RAM do Ubuntu 16.04 od 15.10. Konsekwentnie instaluję aktualizacje. Używam ubuntu ze środowiskiem graficznym Gnome (GDM).

Ostatnio mam dziwny problem, mój procesor (w tym wszystkie 4 rdzenie) jest w 100% wykorzystywany przez niektóre procesy, takie jak gnome-software(oprogramowanie Gnome) i fwupd(demon aktualizacji oprogramowania układowego). To sprawia, że ​​moja praca spada. Jeśli nawet zabiję te procesy, zaczynają się od nowa.

Czy istnieje rozwiązanie pozwalające tym procesom nie wykorzystywać 100% mojego procesora? I nie chcę odpowiedzi z informacją, że użyj tego cpulimitnarzędzia do zapewnienia ilości procesora dla tych procesów. Uważam to za podstawowy problem w Ubuntu, oczekuję prawdziwych rozwiązań tego problemu.

Dotychczas próbowałem usunąć te PPA, które dodałem, z wyjątkiem oficjalnych PPA do sprawdzania aktualizacji. To się nie udało! Załączono zrzut htopekranu przedstawiający te procesy.

Miał podobny problem.

Jak wspomniano w innej odpowiedzi - problem można ustalić, patrząc na niego /var/log/syslog.

W moim dzienniku ustawienia gnome raportowały:

(gnome-settings-daemon:3584): dconf-CRITICAL **: unable to create file '/home/USER/.cache/dconf/user': Permission denied.

Aby to naprawić, uruchomiłem następujące polecenie, zamień USER na swoją nazwę użytkownika:

sudo chown USER /home/USER/.cache/dconf

Miałem dokładnie ten sam problem, te same procesy zajmujące 100% procesora. To, co zadziałało, to aktualizacja oprogramowania w moim Ubuntu (16.04):

sudo apt-get update
sudo apt-get upgrade

Następnie ponownie uruchomiłem komputer i teraz problem zniknął.

Udało mi się to rozwiązać, sprawdzając syslog ( /var/log/syslog). Logował się jak szalony, że nie mógł utworzyć pliku /home/<my user>/.cache/dconf/user. Kiedy nadałem temu folderowi odpowiednie uprawnienia, przestał używać tak dużej ilości procesora.

Problem uprawnień dla mnie.

patrzeć na:

$ cat /var/log/syslog

(gnome-software: 3812): dconf-CRITICAL **: nie można utworzyć pliku „/home/{user}/.cache/dconf/user”: Permiso denegado. dconf nie będzie działał poprawnie.

Wykonanie tego polecenia rozwiązało problem.

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

Może się zdarzyć, że w syslogu nie ma nic związanego z usługą, w takim przypadku możesz po prostu zrestartować go. Aby uniknąć wyszukiwania usług i ich ręcznego zabijania, możesz po prostu użyć systemctl:

sudo systemctl restart fwupd

Ten problem fwupdzdarzył mi się dzisiaj na jednym komputerze. Miałem też dwa przypadki gnome-softwarebiegania. W sumie 2 procesory zostały zablokowane na poziomie 100%.

Aby szybko zatrzymać ten chaos, mógłbym po prostu zabić te 3 procesy:

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

kill <pid1>
kill <pid2>
kill <pid3>
...

(Można także spróbować killall gnome-softwarei killall fwupd, po prostu stwierdzić, że killallpolecenie niebezpieczne ... W przeciwnym razie, w htopmożna po prostu użyć F9. Przed potwierdzeniem, upewnij się, że został wybrany prawidłowy proces!)

Teraz @belacqua wskazał nam następujący raport o błędach na starterze:

https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1591868

Uważam komentarz 18 za szczególnie interesujący:

https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1591868/comments/18

Osoba mówi, że problem nie jest powtarzalny, ale jeśli miałeś problemy z apt-get (jak w przypadku aktualizacji / instalacji oprogramowania), może to być bardzo z tego powodu. I rzeczywiście, miałem kilka plików w apt cache, które były totalnie badziewne (tj. Moje połączenie internetowe nie powiodło się kilka dni temu, a niektóre pliki cache zawierały błąd HTTP 302 zamiast oczekiwanych list pakietów). Znajduję ten konkretny komentarz interesujące, ponieważ błąd nadal istnieje, ale nie z powodu określonego tam pliku yaml. W moim przypadku nie mogłem nigdzie znaleźć żadnego pliku yaml.

Założę się, że naprawiając apt-getpamięć podręczną , naprawiłem problem. Wygląda na to, że kod został już jakiś czas temu naprawiony. Potrzebuję tylko ponownego uruchomienia, aby potwierdzić, że to 100% użycie procesora nie występuje ponownie.

Ten sam problem ze mną, także blokuje mój system.

Po zmianie właściciela /home/{user}/.cache/dconf/userwygląda normalnie.