After Upgrade from 11.10 to 12.04, the login process of Gnome 3 is extremely slow (It takes in the order of 60 seconds when it was in the order of a few seconds before the upgrade (Harddisk is a SSD!)).

Running "top" in a VT shows that gnome-shell is producing about 90% CPU load while dbus-daemon is taking roughly 10%. The moment when CPU-load of gnome-shell drops to normal levels (around 2-3%) corresponds to the time the login process is terminated and the desktop is displayed.

De-activating the four gnome-shell extensions (Alternative Status Menu, Quit Button, Remove Accessibility, system-monitor) that I have installed does not have any effect on session start up time.

Login to Gnome classic does not show the slow session start.

The system logs do not show anything suspicious. Thus, what is the best way to identify the underlying problem?


I had a similar problem, and pinned it down to the contacts system -- I did that by running strace -p on the gnome-shell process, and looking for the contents of the system calls.

I give my eventual solution in my blog entry here. Hope that helps!

--- /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));
| improve this answer | |
  • 1
    Welcome to Ask Ubuntu! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the solution you found here in your answer, and provide the link for reference. – Eliah Kagan Jul 24 '12 at 17:42
  • 1
    Sorry for the late reply. Obviously I have some settings wrong with notifications. :( - The proposed change in /usr/share/gnome-shell/js/ui/overview.js did the trick and I am back to normal login times (a few seconds). Even though that the answer does not exactly address the question (How to debug?), it provides me with a solution for my underlying problem, which is even better for me! Many thanks! – user65521 Aug 23 '12 at 7:03
  • the link is broken – hayd Mar 4 '14 at 6:11

I know this question is ancient, but it shows up near the top of the Google results, so I thought I'd throw up an answer to the question in the title —

One way to identify the problem works like this:

Start to log in to your session, but, also have another session (as another user, or on a "tty" session (Control+Alt+[F2…]), or via ssh, or …) already open, with a text shell (bash) prompt ready.

Key in (but don't hit Return yet) this command:

  • you may need to sudo this command if your other shell is a different user account
  • This is one, long line

gdb attach /usr/bin/gnome-shell $(pgrep -u your login gnome-shell) -ex 'call gjs_dumpstack ()'

e.g. gdb attach /usr/bin/gnome-shell $(pgrep -u jdoe gnome-shell) -ex 'call gjs_dumpstack ()'

As soon as the shell is "too busy," i.e. "catch it in the act," in your other shell, hit Return to trap it. It will freeze up the shell and might kill your login attempt, but you'll have your backtrace.

You'll get a welcome banner from the debugger. (You may also be told that you need to install some debuginfo packages, on Fedora at least, I'm not sure if Ubuntu will do the same, but I presume it's similar. You shouldn't actually need these to debug the JavaScript side of things; that only applies to debugging the C part of the code.)

This will show the stack of active JavaScript functions, which will almost certainly show the culprit.

You can find more detailed information here: https://wiki.gnome.org/Projects/GnomeShell/Debugging

| improve this answer | |

Do you have many pictures and use Nautilus? Maybe you are affected by LaunchPad Bug 505085 - gnome-settings-daemon extensive disk usage? See comment 13 or 18 for workarounds.

| improve this answer | |
  • In my case, it seems that are zeitgeist and tracker to slow down gnome shell startup. The weird thing is that they are not started by the session manager. – the brx in the walls Aug 1 '12 at 8:10

i had same problem and didn't know how to debug. but i deactivated all gnome shell extensions and then it worked perfectly. i know this is not the exact answer to the question but it may help other people with similar problems (slow login to gnome 3 session)

you can deactivate one by one to find out which extension creates the problem - or you deactivate all and activate one by one again ;)

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.