The HAVE_SM macro is used in registryd/registry-main.c to determine whether or not the registry should participate in the X Session Management protocol (http://lesstif.sourceforge.net/doc/super-ux/g1ae04e/chap12.html). The macro is currently typically defined, but I think the implementation in the existing code is incomplete.
There should be something in the code that tears things down and quits the g_main_loop. An example can be found in the AT-SPI/CORBA registry-main.c file. I'm not quite sure what is needed (if anything) to tear down the D-Bus connection, so I was hesitant to provide a simple "just kill g_main_loop" fix. If you can point me to some examples of a D-Bus service gracefully shutting down, I can work on a patch.
BTW, the impact of this is that you get an annoying dialog telling you the process has not quit when you attempt to log out.
Do we need the registry daemon to participate in the X session management protocol? I'm not familiar with this at all. I don't think it is possible for the registry daemon to restore its state, so participating seems a bit pointless.
The registryd cannot store its state because it contains a list of D-Bus addresses for all of the accessible applications on the desktop. Next time the session loads the applications will be assigned different D-Bus addresses.
Is the problem that the registryd doesn't shut down with the X session or that it participates with the X session manager and doesn't respond to its request?
(In reply to comment #1)
> Do we need the registry daemon to participate in the X session management
> protocol? I'm not familiar with this at all. I don't think it is possible for
> the registry daemon to restore its state, so participating seems a bit
I believe we need the registry daemon to participate. We want the gnome-session process to have its GTK_MODULES environment variable set - this is done when the registry starts via a kind of complex mechanism -- the registry *.desktop file is used by gnome-session to launch the registry at gnome-session initialization phase, which is the only point where environment variables can be set in gnome-session. The registryd then connects to the gnome-session via gnome-session's DBus API and tells it to set the GTK_MODULES environment variable. Mind boggling. I believe gnome-session *used* to set GTK_MODULES directly, but I'm guessing this new way was deemed more tasteful by the gnome-session folks.
The reason the GTK_MODULES environment varilable needs to be done is so that any GUI's launched by gnome-session will participate in the accessibility infrastructure. The main issue is that it has to be done at initialization time (Mike determined that gnome-session complains if you try to set environment variables outside of the intialization phase), so it needs to be done via a *.desktop file.
> Is the problem that the registryd doesn't shut down with the X session or that
> it participates with the X session manager and doesn't respond to its request?
I believe it just needs to listen for the shutdown request and then gracefully exit. My problem is that I don't know what it means to gracefully exit from D-Bus (i.e., can the registryd just quit the g_main_loop and exit?).
Yes, on quitting the main loop the program will close down, the socket that is used to connect to the D-Bus bus will close.
I think it states this in the D-Bus documentation, under the dbus_connection_close method it says:
"If a connection is dropped by the remote application, it will close itself."
Hopefully that makes it official. :)
Created attachment 29907 [details] [review]
Patch (lifted from the CORBA-based registryd)
This patch seems to do the trick rather well. It basically adds support to the registry to have it participate in the session management protocol. It was lifted from the CORBA-based code.
Hold off on this patch. The current method seems to cause issues: https://bugzilla.gnome.org/show_bug.cgi?id=578334
If the current patches for bug #24106 is applied, there will be no need for a *.desktop file and there will be no need to communicate with the session manager. That will make this bug obsolete. :-)
As far as I now understand it registryd needs to take part in gnome session because it needs to inform the session manager when its initialization has completed.
Li Yuan provided a patch to participate in gnome session management. This was merged in commit ac85b1dc21843e432ae09b01c29ad2845cf2b41b.