¿Cómo depurar el inicio de sesión lento de Gnome 3?

Después de la actualización de 11.10 a 12.04, el proceso de inicio de sesión de Gnome 3 es extremadamente lento (tarda unos 60 segundos en estar en el orden de unos segundos antes de la actualización (¡el disco duro es un SSD!)).

Ejecutar “top” en un VT muestra que gnome-shell está produciendo aproximadamente el 90% de la carga de la CPU, mientras que dbus-daemon está tomando aproximadamente el 10%. El momento en que la carga de la CPU de gnome-shell cae a niveles normales (alrededor del 2-3%) corresponde al momento en que finaliza el proceso de inicio de sesión y se muestra el escritorio.

La desactivación de las cuatro extensiones gnome-shell (Menú de estado alternativo, Botón Salir, Eliminar accesibilidad, monitor del sistema) que he instalado no tiene ningún efecto en el tiempo de inicio de sesión.

Iniciar sesión en Gnome classic no muestra el inicio de sesión lento.

Los registros del sistema no muestran nada sospechoso. Entonces, ¿cuál es la mejor manera de identificar el problema subyacente?

Tuve un problema similar, y lo strace -p en el sistema de contactos: lo hice ejecutando strace -p en el proceso de gnome-shell y buscando el contenido de las llamadas al sistema.

Doy mi eventual solución en mi entrada de blog aquí . ¡Espero que ayude!

 --- /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)); 

Sé que esta pregunta es antigua, pero se muestra cerca de la parte superior de los resultados de Google, así que pensé en lanzar una respuesta a la pregunta en el título:

Una forma de identificar el problema funciona así:

Comience a iniciar sesión en su sesión, pero, también tiene otra sesión (como otro usuario, o en una sesión “tty” (Control + Alt + [F2 …]), o vía ssh, o …) ya abierta, con un shell de texto (bash) pronta listo.

Teclee (pero no pulse Volver todavía) este comando:

  • Es posible que deba sudo este comando si su otro shell es una cuenta de usuario diferente.
  • Esta es una larga linea

gdb attach /usr/bin/gnome-shell $(pgrep -u su nombre de usuario gnome-shell) -ex 'call gjs_dumpstack ()'

por ejemplo, gdb attach /usr/bin/gnome-shell $(pgrep -u jdoe gnome-shell) -ex 'call gjs_dumpstack ()'

Tan pronto como el shell esté “demasiado ocupado”, es decir, “cójalo en el acto”, en su otro shell, pulse Retorno para atraparlo. Se congelará el shell y podría matar su bash de inicio de sesión, pero tendrá su retroceso.

Obtendrá un banner de bienvenida del depurador. (También es posible que le digan que necesita instalar algunos paquetes debuginfo, al menos en Fedora. No estoy seguro de que Ubuntu haga lo mismo, pero supongo que es similar. No debería necesitar estos para depurar el lado de JavaScript. de cosas; eso solo se aplica a la depuración de la parte C del código.)

Esto mostrará la stack de funciones de JavaScript activas, que casi seguramente mostrarán al culpable.

Puede encontrar información más detallada aquí: https://wiki.gnome.org/Projects/GnomeShell/Debugging

¿Tienes muchas fotos y usas Nautilus? ¿Quizás esté afectado por el error 505085 de LaunchPad – gnome-settings-daemon uso extenso del disco ? Vea el comentario 13 o 18 para las soluciones provisionales.

Tuve el mismo problema y no sabía cómo depurar. pero desactivé todas las extensiones de shell gnome y luego funcionó perfectamente. Sé que esta no es la respuesta exacta a la pregunta, pero puede ayudar a otras personas con problemas similares (inicio de sesión lento en la sesión de gnome 3)

puede desactivar uno por uno para descubrir qué extensión crea el problema, o puede desactivar todos y activar uno por uno nuevamente;)