Le logiciel et le programme de mise à jour consomment 100% de la CPU dans Ubuntu 16.04
J'ai mis à jour mon ordinateur portable (Lenovo Z50-70) qui dispose d'un processeur i7 et de 8 Go de RAM à Ubuntu 16.04 à partir de 15h10. J'ai installé des mises à jour de manière cohérente. J'utilise Ubuntu avec l'environnement de bureau Gnome (GDM).
Dernièrement, j'ai rencontré un problème étrange. Mes processeurs (y compris les 4 cœurs) sont utilisés à 100% par certains processus tels que gnome-software (logiciel Gnome) et fwupd (démon de mise à jour du micrologiciel). Cela rend mon travail en baisse. Si je tue même ces processus, ils recommencent.
Existe-t-il une solution pour que ces processus n'utilisent pas 100% de mon processeur? Et je ne veux pas de réponses disant d'utiliser l'utilitaire cpulimit pour provisionner la quantité de CPU nécessaire à ces processus. Je trouve qu’il s’agit d’un problème fondamental dans Ubuntu et j’attends de vraies solutions.
Ce que j'ai essayé jusqu'à présent, c'est: Supprimer les PPA que j'ai ajoutés, à l'exception des PPA officiels permettant de vérifier les mises à jour. Cela n'a pas fonctionné! Ci-joint une capture d'écran de l'écran htop de ces processus.
Avait un problème similaire.
Comme l’a dit l’autre réponse, il est possible de déterminer le problème en consultant /var/log/syslog.
Dans mon journal, gnome-settings signalait ce qui suit:
(gnome-settings-daemon:3584): dconf-CRITICAL **: unable to create file '/home/USER/.cache/dconf/user': Permission denied.
Afin de résoudre ce problème, j'ai lancé la commande suivante, remplacez USER par votre nom d'utilisateur:
Sudo chown USER /home/USER/.cache/dconf
J'ai eu exactement le même problème, les mêmes processus prenant 100% de la CPU. Ce qui a fonctionné pour moi a été de mettre à jour le logiciel sous Ubuntu (16.04):
Sudo apt-get update
Sudo apt-get upgrade
Après cela, je redémarré mon pc et le problème est maintenant résolu.
J'ai réussi à le résoudre en vérifiant syslog (/var/log/syslog). La journalisation était folle de ne pas pouvoir créer le fichier /home/<my user>/.cache/dconf/user. Lorsque j'ai attribué les autorisations appropriées à ce dossier, il a cessé d'utiliser autant de ressources processeur.
Il peut y avoir un cas où il n'y a rien dans le syslog lié au service, auquel cas vous voudrez peut-être simplement le redémarrer. Pour éviter de rechercher et de tuer manuellement des services, vous pouvez simplement utiliser systemctl:
Sudo systemctl restart fwupd
Problème de permission pour moi.
regarder:
$ cat /var/log/syslog
(gnome-software: 3812): dconf-CRITICAL **: impossible de créer le fichier '/home/{userBuch/.cache/dconf/user': Permiso denegado. dconf ne fonctionnera pas correctement.
En exécutant cette commande, le problème a été résolu.
$ Sudo chown {user} /home/{user}/.cache/dconf
Ce problème avec fwupdm'est arrivé aujourd'hui sur un ordinateur. J'ai également eu deux instances de gnome-software en cours d'exécution. Au total, 2 CPU ont été bloqués à 100%.
Pour arrêter rapidement ce chaos, je pourrais juste tuer ces 3 processus:
ps -ef | less
(find processes in the list, record their PID)
kill <pid1>
kill <pid2>
kill <pid3>
...
(Vous pouvez également essayer killall gnome-software et killall fwupd. Je trouve juste que la commande killallest dangereuse ... Sinon, dans htopvous pouvez simplement utiliser F9. Avant de confirmer, assurez-vous que le processus correct a été sélectionné!)
Maintenant, @ belacqua nous a signalé le rapport de bogue suivant sur le tableau de bord:
https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1591868
J'ai trouvé le commentaire 18 particulièrement intéressant:
https://bugs.launchpad.net/ubuntu/+source/appstream-glib/+bug/1591868/comments/18
La personne a déclaré que le problème n'était pas reproductible, mais si vous rencontriez des problèmes avec apt-get (comme dans la mise à jour/l'installation du logiciel), il est fort possible que ce soit à cause de cela. Et en effet, j'avais plusieurs fichiers dans le cache d'apt qui étaient de la merde totale (c'est-à-dire que ma connexion Internet a échoué il y a quelques jours et que certains des fichiers de cache contenaient une erreur HTTP 302 au lieu des listes de paquets attendus.) Je trouve ce commentaire spécifique intéressant parce qu’un bogue existe toujours, mais pas à cause du fichier yaml spécifié ici. Dans mon cas, je n'ai trouvé aucun fichier yaml.
Je parierais que par en corrigeant le cache apt-get , j'ai résolu le problème. Il semble que le code ait déjà été corrigé. J'ai juste besoin d'un redémarrage pour confirmer que cette utilisation à 100% du processeur ne se reproduira plus.
Même problème avec moi, il bloque également mon système.
Après avoir changé de propriétaire de /home/{user}/.cache/dconf/user, cela semble normal.