After the upgrade gnome-2.28 hog the system with dbus traffic right after the login (gdm... nothing strange). - gnome-panel sometimes didn't appear completely - nautilus didn't show the icons on the desktop - the "Run application..." window appear without controls on it (only the background) no feedback while typing but it can anyway launch my commands - top reveal that dbus process (owner messagebus) hog the cpu - i'll attach the loop output of dbus-monitor - restarting dbus with "/etc/init.d/dbus restart" give me back a functional desktop: nautilus finally draws the icons, and gnome-panel (sometimes with a restart) shows fine.
Loop output from dbus-monitor, anybody knows how to read it? --------------------------------------------------------------- signal sender=org.freedesktop.DBus -> dest=(null destination) serial=212 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.2865" string "" string ":1.2865" method call sender=:1.2865 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello signal sender=org.freedesktop.DBus -> dest=(null destination) serial=213 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.gtk.Private.GduVolumeMonitor" string "" string ":1.2865" method call sender=:1.43 -> dest=org.gtk.Private.GduVolumeMonitor serial=1392 path=/org/gtk/Private/RemoteVolumeMonitor; interface=org.gtk.Private.RemoteVolumeMonitor; member=List method call sender=:1.16 -> dest=org.gtk.Private.GduVolumeMonitor serial=1409 path=/org/gtk/Private/RemoteVolumeMonitor; interface=org.gtk.Private.RemoteVolumeMonitor; member=List method call sender=:1.2865 -> dest=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName string "org.gtk.Private.GduVolumeMonitor" uint32 7 method call sender=:1.2865 -> dest=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch string "type='signal',interface='org.freedesktop.DBus',member='NameOwnerChanged',arg0=':1.43'" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=214 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string "org.gtk.Private.GduVolumeMonitor" string ":1.2865" string "" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=215 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.2865" string ":1.2865" string "" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=216 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.2864" string ":1.2864" string "" signal sender=org.freedesktop.DBus -> dest=(null destination) serial=217 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged string ":1.2866" string "" string ":1.2866" method call sender=:1.2866 -> dest=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello method call sender=:1.2866 -> dest=org.gtk.vfs.Daemon serial=2 path=/org/gtk/vfs/mounttracker; interface=org.gtk.vfs.MountTracker; member=listMountableInfo method return sender=:1.6 -> dest=:1.2866 reply_serial=2 array [ struct { string "http" string "http" array [ ] int32 0 boolean false } struct { string "archive" string "archive" array [ ] int32 0 boolean false } struct { string "davs+sd" string "davs+sd" array [ ] int32 0 boolean false } struct { string "dav+sd" string "dav+sd" array [ ] int32 0 boolean false } struct { string "dns-sd" string "dns-sd" array [ ] int32 0 boolean false } struct { string "smb-server" string "smb" array [ ] int32 0 boolean false } struct { string "smb-network" string "smb" array [ ] int32 0 boolean false } struct { string "davs" string "davs" array [ ] int32 0 boolean false } struct { string "dav" string "dav" array [ ] int32 0 boolean false } struct { string "localtest" string "localtest" array [ ] int32 0 boolean false } struct { string "sftp" string "sftp" array [ string "ssh" ] int32 22 boolean true } struct { string "smb-share" string "smb" array [ ] int32 0 boolean false } struct { string "cdda" string "cdda" array [ ] int32 0 boolean false } struct { string "ftp" string "ftp" array [ ] int32 21 boolean true } struct { string "burn" string "burn" array [ ] int32 0 boolean false } struct { string "trash" string "trash" array [ ] int32 0 boolean false } struct { string "obex" string "obex" array [ ] int32 0 boolean false } struct { string "computer" string "computer" array [ ] int32 0 boolean false } struct { string "network" string "network" array [ ] int32 0 boolean false } struct { string "gphoto2" string "gphoto2" array [ ] int32 0 boolean false } ]
Created attachment 231385 [details] emerge --info
Well... some more useful info: - revdep-rebuild done... - compiz re-emerged (same behaviour with and without compiz in startup applications...) - applets in my panel: deskbar-applet, keyboard, notes, system monitor, cpu and disk temperatures, lockdown (all functional after the dbus restart) - startup applications: - /usr/libexec/gnome-settings-daemon - gnome-keyring-daemon --start - seahorse-daemon - /usr/libexec/gnome-volume-manager --sm-disable - /usr/lib64/gnome-session/helpers/gnome-settings-daemon-helper - /usr/libexec/gdu-notification-daemon - beagled --replace - gnome-screensaver - gnome-do - dropbox - tilda
Found the source of the problem (but i still don't know why). Adding the menu-bar applet or the menu button to a panel starts the loop messages through dbus. After a "killall gnome-panel" (no need to restart the dbus system service) the panel reappear with the menubar working (even if the "Edit menu" doesn't start the editor). Logging in the system with a other "quite fresh" user there's no cpu hog, so it's probably related (i think) about my customized ".desktop" files. Anyway it's sound strange for me that a restart of gnome-panel didn't generate the dbus traffic, while at the gnome initialization (or adding the applet to a panel) does.
(In reply to comment #4) > Logging in the system with a other "quite fresh" user there's no cpu hog, so > it's probably related (i think) about my customized ".desktop" files. > Anyway it's sound strange for me that a restart of gnome-panel didn't generate > the dbus traffic, while at the gnome initialization (or adding the applet to a > panel) does. > This is invalid then as it's caused by some wrong configuration. Please only reopen this if you are able to see how to reproduce on a new created user account. Thanks
You are welcome Pacho, anyway I'm not totally agree to mark it invalid (nothing personal i know, it's just a bug ;-)). I know the problem it's strictly related to a specific configuration of my account but there are some things to consider. Speaking in general (I've to investigate deeper, but these are my first general considerations) 1. It's a valid gnome-2.26 configuration, so it has to be a valid 2.28 configuration too (or migrated in the right way) 2. Starting with a whole fresh configuration may be not always a feasible way (even if I think that probably it's not needed here... as I said before I've to check) More specifically: the message loop on dbus starts when the menu-related applets are initialized. This applet "simply" have to deal with .desktop files. If the problem appears (as I believe) for some customized .desktop file there's something to fix, especially if it has those consequences. I'll try to test removing my .share/applications folder (not this weekend), in the meantime if you know some "dbus-expert" to investigate in that way I'll offer a beer!
The problem is that it's not possible to solve the problem if we are unable to know what exact configuration if causing this, as we don't have any idea about how to try to reproduce :-/
I know... unlucky..:p any tips that could help me debug/strace the initializing of the applets? Anyway I'll let u know if the problem disappear simply removing the .local/share/applications (that's the main difference between my two accounts, that in my opinion could be related to the problem) in that case will be easier to reproduce (i hope)
Usually taking a look on ~/.xsession-errors while it's failing can give some information
After looking at xsession-errors i found something useful. I'm in the exactly same situation of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573720 Removing all gnome configuration files in the "faulty" account doesn't solve the problem, so I'm trying now to find why the other user work.
