GNOME Bugzilla – Bug 646177
notifications: race at login
Last modified: 2011-04-04 01:47:02 UTC
I notice that abrt and nm-applet are still creating statusicons when running under the shell. They have both been patched to check the notification service for persistence, and _not_ create a statusicon if it is present. But they both do so early on during login, and I see the following in .xession-errors (after patching libnotify to not eat the error message): (abrt-applet:1566): libnotify-WARNING **: Failed to connect to proxy: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "GetServerInformation" with signature "" on interface "org.freedesktop.Notifications" doesn't exist Failed to receive server caps. (nm-applet:1561): libnotify-WARNING **: Failed to connect to proxy: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: Method "GetServerInformation" with signature "" on interface "org.freedesktop.Notifications" doesn't exist So, I guess the shell is claiming the name org.freedesktop.Notifications early on, but only gets around to implementing the interfaces when javascript gets loaded. I even tried adding the notification-daemon service file back to see if I could have the daemon activated early and then have the shell replace it, but that does not help either. Probably because the shell has already taken the name by the time abrt calls GetServerInformation.
So this isn't obvious to me why it's happening: gnome-shell/src/main.c:shell_dbus_init() * We request org.freedestkop.Notifications synchronously meta_run(): * Connect via XSMP to gnome-session; this tells it we're ready, and thus starts autospawning everything else * Call meta_run() mutter/src/core/main.c:meta_display_open() * Opens the X display * Calls into meta_compositor_manage_screen which calls plugin->start gnome-shell/src/gnome-shell-plugin.c: * Calls imports.ui.main.start() Ohhh but! Before all this, in meta_init, we call meta_clutter_init() which initializes both Clutter and GDK.
My initial theory was that in some point in the initialization path we were reentering the mainloop. Still looking at that, but another problem is that gjs always connects to the bus in an idle.
In js/ui/main.js, we call DBus.session.flush(); the intent of this call was to force a connection. But it's a problem, because this can cause us to process pending messages. I think what we need to try is adding a method DBus.session.connect_now() and using that in main.js.
Created attachment 184709 [details] [review] main.js: Synchronously connect to session bus, but don't flush If we flush, we may end up processing pending messages, with negative consequences if we haven't yet actually exported objects.
Hm, but i'm still seeing the bug =( I think these patches are an improvement though anyways.
Wait a minute...i'm actually getting this even after login normally.
(In reply to comment #6) > Wait a minute...i'm actually getting this even after login normally. This turned out to be bug 646257, which is unrelated. The real bug is in gjs; we're doing the connection exports out of an idle. I'll update bug 646246
(In reply to comment #7) > The real bug is in gjs; we're doing the connection exports out of an idle. > I'll update bug 646246 Is there anything left to this bug then?
(In reply to comment #8) > (In reply to comment #7) > > The real bug is in gjs; we're doing the connection exports out of an idle. > > I'll update bug 646246 > > Is there anything left to this bug then? I don't think so - we decided that we should just make exportObject reliably export the object rather than having some call you had to make afterwards "oh, yeah, and export it *now*, before you accept any more incoming calls". *** This bug has been marked as a duplicate of bug 646246 ***