GNOME Bugzilla – Bug 526984
Make gnome-settings-daemon work nicely with gnome-session
Last modified: 2008-04-21 18:59:03 UTC
The new gnome-session requires default session modules (gnome-settings-daemon, gnome-panel, nautilus, metacity, etc) to install their .desktop files in one of the standard autostart directories. IIUC, it doesn't make much sense to make g-s-d a XSMP client because it's being used by GDM too. Hence, gnome-settings-daemon is not connecting to the session daemon (i.e. using GnomeClient). However, in the new session manager, we need to make g-s-d confirm it was successully launched on session startup. So, here's my suggestion: We could have a helper program which just checks if g-s-d. If it's not running, it makes a D-Bus call to start it. After everything is checked, the helper program just exists. The new gnome-session manager recognizes a clean exit of "Initialization" phase apps as a successful launch and then it moves on. The .desktop file would reference this helper program instead of the g-s-d executable. This helper program would basically do something similar than this one: http://svn.gnome.org/svn/gnome-session/trunk/compat/at-spi-registryd-wrapper.c We would still need to solve the program cleanly stop g-s-d (see bug #522017) Comments? After we agree on a solution, I can work on a patch.
I'd prefer making it an XSMP client. However, since I have no idea how gdm uses it or what it needs, I guess Jon's the one best equipped to answer this.
Of course that having g-s-d as a XSMP client makes everything much simpler but let's see if it makes sense on all cases. IIRC, g-s-d used to be a XSMP anyway. :-)
Hey guys, we need to agree on something asap. It would be really nice to have a fully working default session for 2.23.1. :-)
On IRC the point came up that XSMP is a deprecated protocol. But we don't want a wrapper, either. ;-) Would it be sufficient if we just daemonized g-s-d after plugins have successfully loaded?
(In reply to comment #4) > On IRC the point came up that XSMP is a deprecated protocol. But we don't want > a wrapper, either. ;-) I think everyone agrees that XSMP should be decrecated asap. :-) However, it's still been used by all(?) free desktop session managers. Context: the final goal is to get rid of XSMP but at this moment the idea is to just migrate GNOME to the new gnome-session still based on XSMP. This new gnome-session will make it easier to move to a new D-Bus-based SM protocol in the future. > Would it be sufficient if we just daemonized g-s-d after plugins have > successfully loaded? Could you elaborate? Also, could you please explain how g-s-d is being used by GDM? Is it so that when gnome-session starts, g-s-d might be already running? I always thought of g-s-d as session daemon so the current setup seems quite strange. As a session daemon, it would make sense to have g-s-d as session client (like power manager, for example).
(In reply to comment #5) > Context: the final goal is to get rid of XSMP but at this moment the idea is to > just migrate GNOME to the new gnome-session still based on XSMP. This new > gnome-session will make it easier to move to a new D-Bus-based SM protocol in > the future. Well, that would mean pulling in libgnomeui and depending even more on gnome_program_init which we want to get rid of, anyway. > > Would it be sufficient if we just daemonized g-s-d after plugins have > > successfully loaded? > > Could you elaborate? The purpose of the wrapper script seems to be to detach the process which g-s will then consider a successful launch. So we should be able to just detach g-s-d when plugins have been loaded, should we not? > Also, could you please explain how g-s-d is being used by GDM? Is it so that > when gnome-session starts, g-s-d might be already running? You should really harrass mccann to explain that. AFAIUI, gdm runs its own private instance of g-s-d. Presumably, that one is shut down before the session is started, so no, g-s-d should not be running already.
(In reply to comment #6) > (In reply to comment #5) > > Context: the final goal is to get rid of XSMP but at this moment the idea is to > > just migrate GNOME to the new gnome-session still based on XSMP. This new > > gnome-session will make it easier to move to a new D-Bus-based SM protocol in > > the future. > > Well, that would mean pulling in libgnomeui and depending even more on > gnome_program_init which we want to get rid of, anyway. On the other hand, having g-s-d as a session client has its benefits as well. For example, we can garantee that g-s-d will always be running by setting its restart style and having the session manager to restart it in case it crashes. How do you currently this, btw? Another benefit would be to have it cleanly stopped by gnome-session when the desktop session is finished (by connecting to "die" signal). Maybe those benefits are not relevant to g-s-d for some reason. Let me know what you think. If you think that not depending on libgnomeui is more important, you can either implement your own session client code (like metacity does), you can have a copy EggSMClient from gnome-session, or we can try to solve it in another way (which is still unclear). Any of those solutions have pros and cons. > > > Would it be sufficient if we just daemonized g-s-d after plugins have > > > successfully loaded? > > > > Could you elaborate? > > The purpose of the wrapper script seems to be to detach the process which g-s > will then consider a successful launch. So we should be able to just detach > g-s-d when plugins have been loaded, should we not? Yes, I guess so. The important thing is that the wrapper checks/runs a g-s-d and exits as soon as possible. > > Also, could you please explain how g-s-d is being used by GDM? Is it so that > > when gnome-session starts, g-s-d might be already running? > > You should really harrass mccann to explain that. AFAIUI, gdm runs its own > private instance of g-s-d. Presumably, that one is shut down before the session > is started, so no, g-s-d should not be running already. John, could you give some GDM context here? :-)
(In reply to comment #7) > On the other hand, having g-s-d as a session client has its benefits as well. > For example, we can garantee that g-s-d will always be running by setting its > restart style and having the session manager to restart it in case it crashes. > How do you currently this, btw? Er, we have nothing to do with that. Ask gnome-session. > Another benefit would be to have it cleanly > stopped by gnome-session when the desktop session is finished (by connecting to > "die" signal). There is another bug (bug 525859) asking for a dbus API for gnome-session to use for that purpose. Do I sense some left hand, right hand disconnect here? That said, yes, I'd certainly prefer the signal to dbus. > Maybe those benefits are not relevant to g-s-d for some reason. > Let me know what you think. > If you think that not depending on libgnomeui is more important, you can either > implement your own session client code (like metacity does), you can have a > copy EggSMClient from gnome-session, or we can try to solve it in another way > (which is still unclear). Any of those solutions have pros and cons. gnome_program_init is slowing us down. Lots. One of the others might work. > > The purpose of the wrapper script seems to be to detach the process which g-s > > will then consider a successful launch. So we should be able to just detach > > g-s-d when plugins have been loaded, should we not? > > Yes, I guess so. The important thing is that the wrapper checks/runs a g-s-d > and exits as soon as possible. FWIW, g-s-d in trunk now daemonizes by default. Does that work for you?
(In reply to comment #8) > (In reply to comment #7) > > On the other hand, having g-s-d as a session client has its benefits as well. > > For example, we can garantee that g-s-d will always be running by setting its > > restart style and having the session manager to restart it in case it crashes. > > How do you currently this, btw? > > Er, we have nothing to do with that. Ask gnome-session. Yes, you have (if you want, of course). :-) In order to have gnome-session keeping track of client disconnections and reacting accordingly, we need to have a session client on g-s-d side. > > Another benefit would be to have it cleanly > > stopped by gnome-session when the desktop session is finished (by connecting to > > "die" signal). > > There is another bug (bug 525859) asking for a dbus API for gnome-session to > use for that purpose. Do I sense some left hand, right hand disconnect here? > That said, yes, I'd certainly prefer the signal to dbus. Yes, we could use the "SessionOver" signal for that. Seems generic enough. My point about the "die" signal is that you would get "SessionOver"-like notification for free. > > Maybe those benefits are not relevant to g-s-d for some reason. > > Let me know what you think. > > > If you think that not depending on libgnomeui is more important, you can either > > implement your own session client code (like metacity does), you can have a > > copy EggSMClient from gnome-session, or we can try to solve it in another way > > (which is still unclear). Any of those solutions have pros and cons. > > gnome_program_init is slowing us down. Lots. One of the others might work. > > > > The purpose of the wrapper script seems to be to detach the process which g-s > > > will then consider a successful launch. So we should be able to just detach > > > g-s-d when plugins have been loaded, should we not? > > > > Yes, I guess so. The important thing is that the wrapper checks/runs a g-s-d > > and exits as soon as possible. > > FWIW, g-s-d in trunk now daemonizes by default. Does that work for you? I guess so. Let me test it to confirm. So, it seems we agreed on: - Daemonize g-s-d to notify gnome-session that it was successfully run - g-s-d keeps track of "SessionOver" signal from gnome-session in order to shutdown cleanly on logout Right?
So, the daemonize in g-s-d doesn't work for session startup because g-s uses spawn_async. So, for the startup, we can either use a wrapper program (as I suggested) or just use a session client. Well, there might be another solution, dunno. If it's a problem for GDM to use g-s-d with the session client, we could disabled session stuff in case g-s-d is launched through D-Bus...
Sorry, there was a problem in my environment which made me thing the daemonize thing wasn't working. Actually, it works very well. We just need to make g-s-d install its .desktop file in one of the standard autostart directories. Patch comes tomorrow because I need to sleep now. :-)
Created attachment 109626 [details] [review] Simple patch This patch basically installs a (new) g-s-d .desktop file in the standard autostart directory. It would be really nice if we could have this for 2.23.1.
Commited in trunk (with Jens approval). Thanks! 2008-04-21 Lucas Rocha <lucasr@gnome.org> Install .desktop for gnome-settings-daemon in a standard autostart directory as required by new gnome-session (bug #526984). * configure.ac: expand $libexecdir to be used on .desktop file. * acinclude.m4: added new m4 macro (AS_AC_EXPAND) for expanding variables. * data/Makefile.am, data/gnome-settings-daemon.desktop.in.in: install g-s-d .desktop file.