web-dev-qa-db-fra.com

Comment déboguer le début de session lent de Gnome 3?

Après la mise à niveau de 11h10 à 12h04, le processus de connexion de Gnome 3 est extrêmement lent (il prend environ 60 secondes lorsqu'il était dans l’ordre de quelques secondes avant la mise à niveau (Harddisk est un SSD!)).

Lancer "top" dans un VT montre que gnome-Shell produit environ 90% de la charge du processeur, tandis que dbus-daemon en prend environ 10%. Le moment où la charge du processeur de gnome-Shell redevient normale (environ 2 à 3%) correspond au moment où le processus de connexion est terminé et le bureau affiché.

La désactivation des quatre extensions gnome-Shell (Menu d’état alternatif, Bouton de fermeture, Supprimer l’accessibilité, Moniteur système) que j’ai installées n’a aucun effet sur le temps de démarrage de la session.

La connexion à Gnome classic ne montre pas le début de session lent.

Les journaux système ne montrent rien de suspect. Ainsi, quel est le meilleur moyen d'identifier le problème sous-jacent?

12.04gnome
6
user65521

J'ai eu un problème similaire et je l'ai épinglé au système de contacts. Je l'ai fait en exécutant strace -p sur le processus gnome-Shell et en recherchant le contenu des appels système.

Je donne ma solution éventuelle dans mon entrée de blog ici . J'espère que ça t'as aidé!

--- /usr/share/gnome-Shell/js/ui/overview-dist.js   2012-07-20 13:12:23.564769756 -0700
+++ /usr/share/gnome-Shell/js/ui/overview.js    2012-07-20 16:40:14.076527986 -0700
@@ -210,7 +210,7 @@
         this.addSearchProvider(new AppDisplay.AppSearchProvider());
         this.addSearchProvider(new AppDisplay.SettingsSearchProvider());
         this.addSearchProvider(new PlaceDisplay.PlaceSearchProvider());
-        this.addSearchProvider(new ContactDisplay.ContactSearchProvider());
+        // this.addSearchProvider(new ContactDisplay.ContactSearchProvider());

         // Load remote search providers provided by applications
         RemoteSearch.loadRemoteSearchProviders(Lang.bind(this, this.addSearchProvider));
2
Danny O'Brien

Je sais que cette question est ancienne, mais elle apparaît presque en haut des résultats Google. J'ai donc pensé proposer une réponse à la question dans le titre -

Une façon d'identifier le problème fonctionne comme ceci:

Commencez à vous connecter à votre session, mais ayez également une autre session (en tant qu'autre utilisateur, ou sur une session "tty" (Ctrl + Alt + [F2…]), ou via ssh, ou…) déjà ouverte, avec un shell de texte (bash) Invite prête.

Entrez (mais ne frappez pas encore Retour) cette commande:

  • vous devrez peut-être Sudo cette commande si votre autre shell est un compte d'utilisateur différent
  • C'est une longue ligne

gdb attach /usr/bin/gnome-Shell $(pgrep -u votre identifiant gnome-Shell) -ex 'call gjs_dumpstack ()'

par exemple. gdb attach /usr/bin/gnome-Shell $(pgrep -u jdoe gnome-Shell) -ex 'call gjs_dumpstack ()'

Dès que le shell est "trop ​​occupé", c'est-à-dire "attrapez-le en flagrant délit", dans votre autre shell, cliquez sur Retour pour le piéger. Cela gèlera le shell et pourrait tuer votre tentative de connexion, mais vous aurez votre trace.

Vous recevrez une bannière de bienvenue du débogueur. (On vous dira peut-être aussi que vous devez installer des paquets debuginfo, du moins sur Fedora. Je ne sais pas si Ubuntu fera de même, mais je suppose que c'est similaire. Vous ne devriez pas en avoir besoin pour déboguer le côté JavaScript. Cela ne concerne que le débogage de la partie C du code.)

Cela montrera la pile de fonctions JavaScript actives, ce qui montrera presque certainement le coupable.

Vous pouvez trouver des informations plus détaillées ici: https://wiki.gnome.org/Projects/GnomeShell/Debugging

2
BRPocock

Avez-vous beaucoup de photos et utilisez Nautilus? Peut-être êtes-vous affecté par bogue 505085 du LaunchPad - utilisation étendue du disque de gnome-settings-daemon ? Voir le commentaire 1 ou 18 pour contourner le problème.

1
shaddow

j'ai eu le même problème et je ne savais pas comment déboguer. mais j’ai désactivé toutes les extensions de gnome Shell, puis cela a parfaitement fonctionné. Je sais que ce n'est pas la réponse exacte à la question, mais cela peut aider d'autres personnes ayant des problèmes similaires (connexion lente à la session gnome 3)

vous pouvez désactiver un par un pour savoir quelle extension crée le problème - ou vous désactivez tout et activez un par un à nouveau;)

0
mgafner