Software e Updater consomem 100% da CPU no Ubuntu 16.04

Atualizei meu laptop (Lenovo Z50-70), que possui uma CPU i7 e 8Gigs de Ram para o Ubuntu 16.04 a partir da 15.10. Venho instalando atualizações de forma consistente. Estou usando o ubuntu com o ambiente de desktop Gnome (GDM).

Ultimamente, estou enfrentando um problema estranho, minha CPU (incluindo todos os 4 núcleos) é 100% usada por alguns processos como gnome-software(software Gnome) e fwupd(daemon de atualização de firmware). Isso faz meu trabalho diminuir. Se eu matar esses processos, eles estão começando de novo.

Existe uma solução para esses processos para não utilizar 100% da minha CPU. E não quero respostas dizendo: use o cpulimitutilitário para provisionar a quantidade de CPU para esses processos. Acho isso um problema central no Ubuntu, estou esperando soluções reais para o problema.

O que eu tentei até agora é remover os PPAs que eu adicionei, exceto os PPAs oficiais para verificar as atualizações. Isso não deu certo! Anexada uma captura de htoptela da tela desses processos.

Teve um problema semelhante.

Como a outra resposta mencionada - é possível determinar o problema olhando /var/log/syslog.

Dentro do meu log, o gnome-settings estava relatando o seguinte:

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

Para corrigir isso, executei o seguinte comando, substitua USER pelo seu nome de usuário:

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

Eu tive exatamente o mesmo problema, os mesmos processos usando 100% da CPU. O que funcionou para mim foi atualizar o software no meu Ubuntu (16.04):

sudo apt-get update
sudo apt-get upgrade

Depois disso, reiniciei o meu PC e agora o problema se foi.

Consegui resolvê-lo verificando syslog ( /var/log/syslog). Estava logado como uma loucura que não conseguia criar o arquivo /home/<my user>/.cache/dconf/user. Quando dei a essa pasta as permissões corretas, ela parou de usar tanta CPU.

Problema de permissão para mim.

olhando para:

$ cat /var/log/syslog

(gnome-software: 3812): dconf-CRITICAL **: não é possível criar o arquivo '/home/{user}/.cache/dconf/user': Permiso denegado. O dconf não funcionará corretamente.

Executando este comando, o problema foi resolvido.

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

Pode haver um caso em que não há nada no syslog relacionado ao serviço; nesse caso, você pode simplesmente querer reiniciá-lo. Para evitar procurar serviços e matá-los manualmente, você pode apenas usar systemctl:

sudo systemctl restart fwupd

Esse problema fwupdaconteceu comigo hoje em um computador. Eu também tive duas instâncias degnome-software execução. No total, 2 CPU foram fixadas em 100%.

Para parar rapidamente esse caos, eu poderia simplesmente matar esses 3 processos:

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

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

(Você também pode tentar killall gnome-softwaree killall fwupd, apenas acho esse killallcomando perigoso ... Caso contrário, htopvocê pode usar o F9. Antes de confirmar, verifique se o processo correto foi selecionado!)

Agora, @belacqua nos indicou o seguinte relatório de bug na barra de lançamento:

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

Achei o comentário 18 particularmente interessante:

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

A pessoa diz que o problema não é reproduzível, mas se você teve problemas com o apt-get (como em atualização / instalação de software), pode ser que seja por isso. E, de fato, eu tinha vários arquivos no cache do apt que eram uma porcaria total (ou seja, minha conexão com a Internet falhou há alguns dias atrás e alguns dos arquivos de cache incluíram um erro HTTP 302 em vez das listas de pacotes esperadas.) Acho esse comentário específico interessante porque ainda existe um bug, mas não devido ao arquivo yaml conforme especificado lá. No meu caso, não encontrei nenhum arquivo yaml em lugar algum.

Aposto que, corrigindo o apt-getcache , resolvi o problema. Parece que o código já foi corrigido há um tempo. Eu só preciso de uma reinicialização para confirmar que esse uso de 100% da CPU não ocorre novamente.

Mesmo problema comigo, também está bloqueando meu sistema.

Depois de mudar de proprietário /home/{user}/.cache/dconf/user, parece normal.