9

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?

4 Answers 4

3

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

2

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));
3
  • 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. Jul 24, 2012 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, 2012 at 7:03
  • the link is broken
    – hayd
    Mar 4, 2014 at 6:11
1

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.

1
  • 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. Aug 1, 2012 at 8:10
0

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .