(Feisty) DBUS hangs after Gnome Login

Looks more like tracker was not installed correctly or something along that line

//DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name
//org.freedesktop.Tracker was not provided by any .service files

Correct installation of tracker should put the tracker.service file in session_bus_services_dir (as defined in dbus-1.pc in /usr/lib/pkgconfig)

Pls check:

1) you have dbus-1.pc
2) it contains the line : session_bus_services_dir=${prefix}/share/dbus-1/services
3) you have --prefix=/usr

Sebastian Dröge schrieb:

> Looks more like tracker was not installed correctly or something along
> that line

Well you're right, there was a deskbar-tracker-05.py
in my .gnome2/deskbar-... directory. (I had it installed months ago on
another computer and migrated my home directory to this one)

But, the dbus process died nevertheless when I logged in (after that). I
had to restart it manually to regain full functionality.

--
Bye,
 Patrick Cornelissen
 http://www.p-c-software.de
 ICQ:15885533

Patrick Cornelissen schrieb:

> But, the dbus process died nevertheless when I logged in (after that). I
> had to restart it manually to regain full functionality.

"(After that)" => (After I deleted the py file)

--
Bye,
 Patrick Cornelissen
 http://www.p-c-software.de
 ICQ:15885533

If dbus session bus is dying on startup then this is probably a dbus bug

Install the libdeskbar-tracker package instead, which contains the deskbar-applet tracker plugin.
If you still get crashes on login, could you please test if you can run "/usr/lib/deskbar-applet/deskbar-applet -w" from the command line successfully.
libdeskbar-tracker uses python-dbus, maybe DBUS_SESSION_BUS_ADDRESS is not correctly passed from gnome-panel to deskbar-applet.

Michael Biebl schrieb:
> Install the libdeskbar-tracker package instead, which contains the
> deskbar-applet tracker plugin. If you still get crashes on login,
> could you please test if you can run
> "/usr/lib/deskbar-applet/deskbar-applet -w" from the command line
> successfully. libdeskbar-tracker uses python-dbus, maybe
> DBUS_SESSION_BUS_ADDRESS is not correctly passed from gnome-panel to
> deskbar-applet.

I have already switched to the ubuntu package. The result is the same.
After Login I get the crash message from deskbar and DBus is dead.
From my point of view, it's he fault of dbus.
Everything happens at the same time, so there is no chance (that I see)
to see which dies first.
My theory is that dbus dies and this triggers the error in deskbar.

I was able to open the deskbar with the commandline you provided and use
the tracker search for example. (DBus died not)

--
Bye,
 Patrick Cornelissen
 http://www.p-c-software.de
 ICQ:15885533

Hi

I have removed deskbar from my gnome panel, but Dbus still hangs
(silently) when I log in.

I'm still pretty confident that this is not a Tracker problem.

Is there any way to get a backtrace, error log or whatever from dbus, to
see what happens when it freezes?

Here are all running DBus related processes:

~$ ps awux|grep dbus
103 5366 0.0 0.0 2840 1080 ? Ss 08:08 0:00
/usr/bin/dbus-daemon --system
root 5534 0.0 0.0 2708 1204 ? S 08:08 0:00
dbus-daemon --session --print-address --nofork
dhcp 5581 0.0 0.0 2456 1172 ? S 08:08 0:00
/sbin/dhclient -1 -lf /var/lib/dhcp3/dhclient.eth0.leases -pf
/var/run/dhclient.eth0.pid -q -e dhc_dbus=31 -d eth0
cornelis 6118 0.0 0.0 4220 632 ? Ss 08:12 0:00
/usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session
x-session-manager
cornelis 6121 0.0 0.0 2512 624 ? S 08:12 0:00
/usr/bin/dbus-launch --exit-with-session x-session-manager
cornelis 6122 0.0 0.0 2840 1048 ? Ss 08:12 0:00
/usr/bin/dbus-daemon --fork --print-pid 4 --print-address 7 --session
cornelis 6688 0.0 0.0 2904 816 pts/0 S+ 08:17 0:00 grep dbus

The symptoms I see are for example that the drive icons are not visible

--
Bye,
 Patrick Cornelissen
 http://www.p-c-software.de
 ICQ:15885533

Same problem for me. It hangs, then crashes, but not completely (the icon stays in the panel, but is unusable)

It seems to happen when trackerd is not yet ready to accept requests yet (I think it's validating its index), but deskbar initializes its tracker bits.

For some reason, this makes it try to start another trackerd (according to my trace), which exits immediately because another trackerd is already running (from /etc/xdg/autostart). This exiting generates an untrapped error in the Python code.

Killing deskbar after login, and then reloading it (trackerd is done validating its cache by then), makes it work.

Martijn van de Streek schrieb:
> It seems to happen when trackerd is not yet ready to accept requests yet
> (I think it's validating its index), but deskbar initializes its tracker
> bits.
>
> For some reason, this makes it try to start another trackerd (according
> to my trace), which exits immediately because another trackerd is
> already running (from /etc/xdg/autostart). This exiting generates an
> untrapped error in the Python code.
>
> Killing deskbar after login, and then reloading it (trackerd is done
> validating its cache by then), makes it work.

Try to remove the deskbar from the panel and login again in gdm.
Do you also have the problem with the missing drive icons and the
hanging dbus?

I think the tracker problem is triggered by a dbus error.
This is consistent with your statement, because when dbus is not
available the tracker plugin is not able to find the trackerd, but the
trackerd uses another criteria to find whether another trackerd is
running. This leads to the error we're getting

--
Bye,
 Patrick Cornelissen
 http://www.p-c-software.de
 ICQ:15885533

If I remove deskbar, and login, nothing hangs.

If I start deskbar before trackerd is done checking its cache, a python error is triggered (uncaught exception, something about starting trackerd) and it hangs.

If I start deskbar after trackerd is done, everything is fine.

This should be fixed in latest svn - we now do the watching process in a separate thread (this can take a long time if you have deep directory trees which might be causing a dbus timeout and hence the crash in deskbar)

I cant confirm yet as I dont run Feisty

I still have this annoying problem that I have to restart dbus each time I login to gnome.
I have removed the deskbar with the trackerplugin, Trackerd is not started via session handling:

cornelis@panorama:~$ ps auwx|grep tracker
cornelis 16575 0.0 0.0 2900 808 pts/0 S+ 11:48 0:00 grep tracker

But DBus hangs... (Or it doesn't behave as it should do)
This is the dbus related stuff:

cornelis@panorama:~$ ps auxw|grep dbus
103 16050 0.1 0.0 2848 1108 ? Ss 11:47 0:00 /usr/bin/dbus-daemon --system
root 16195 0.0 0.0 2716 1216 ? S 11:47 0:00 dbus-daemon --session --print-address --nofork
dhcp 16206 0.0 0.0 2460 1236 ? S 11:47 0:00 /sbin/dhclient -1 -lf /var/lib/dhcp3/dhclient.eth0.leases -pf /var/run/dhclient.eth0.pid -q -e dhc_dbus=31 -d eth0
cornelis 16288 0.0 0.0 4232 636 ? Ss 11:47 0:00 /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session x-session-manager
cornelis 16291 0.0 0.0 2512 628 ? S 11:47 0:00 /usr/bin/dbus-launch --exit-with-session x-session-manager
cornelis 16292 0.0 0.0 2848 1052 ? Ss 11:47 0:00 /usr/bin/dbus-daemon --fork --print-pid 4 --print-address 8 --session
cornelis 16579 0.0 0.0 2904 812 pts/0 R+ 11:48 0:00 grep dbus

There is no crash dialog appearing or something like that. I see no log entries that may be related to this.
Is there anything I can do to raise the verbosity or check the "health status" of dbus?

I only see that the drive icons are missing and software that depends on dbus takes ages to do something.

When I start dbus monitor I see this:

cornelis@panorama:/var/log$ dbus-monitor
signal sender=org.freedesktop.DBus -> dest=:1.14 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.14"
method call sender=:1.14 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='method_call'"
method call sender=:1.14 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='method_return'"
method call sender=:1.14 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='error'"
signal sender=:1.6 -> dest=(null destination) path=/net/sf/gaim/GaimObject; interface=net.sf.gaim.GaimInterface; member=UpdateIdle
signal sender=:1.6 -> dest=(null destination) path=/net/sf/gaim/GaimObject; interface=net.sf.gaim.GaimInterface; member=UpdateIdle
signal sender=:1.6 -> dest=(null destination) path=/net/sf/gaim/GaimObject; interface=net.sf.gaim.GaimInterface; member=UpdateIdle
signal sender=:1.6 -> dest=(null destination) path=/net/sf/gaim/GaimObject; interface=net.sf.gaim.GaimInterface; member=UpdateIdle
...

Any idea what may be going on here?

Yeah, I have dbus-issues as well. The tracker issue is a separate issue:

  https://launchpad.net/ubuntu/+source/tracker/+bug/85029

Lets monitor that one over there and keep this one about dbus not working after logout-login.

I noticed this, because I use the music-player applet.

Steps to reproduce:
  - sudo aptitude install music-applet
  - add music-applet to the panel

It uses dbus to launch and control rhythmbox.
It won't launch rhythmbox after I logout-login.
If I launch rhythmbox manually, it won't get notified. (normally it would show the play-pause-buttons, etc. if I start it manually)

So, the DBUS issue is real. So is the tracker-issue. They are separate. So lets link this bug report to the dbus-package, and not the tracker-package. The other bug-report already links to the tracker-bug upstream and a new version should fix those problems. (a current workaround for the tracker/deskbar issue, is to remove trackerd from your session)

One more confirmation. I have this issue on fresh installation of Medibuntu Feisty LTSP.

I am trying to avoid this issue by not updating dbus and dbus-utils after installation. This did not help.

First symptom: Gnome settings daemon is giving an error when logging in first time after updates and reboot.

Hi,

Is this still a problem for anyone on later releases? The last
confirmation is from feisty as far as I can see,

Can I confirm my impression of the problem? Upon logging in
the dbus system bus (not the session bus) is hanging, and has
to be restarted? This happens every time? How do you determine
that the bus has hung? What do you do to restart it? Is it always
fine after a restart?

Thanks,

James

Can't confirm this with 8.10 anymore

It looks from all reports like this is fixed in the more recent Ubuntu releases