After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 522017 - needs to stop gnome-settings-daemon cleanly
needs to stop gnome-settings-daemon cleanly
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: general
2.23.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
Depends on: 525859
Blocks:
 
 
Reported: 2008-03-12 14:09 UTC by Sebastien Bacher
Modified: 2008-05-27 20:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22


Attachments
Make g-s-d listen to SessionOver D-Bus signal to exit cleanly on session end. (3.93 KB, patch)
2008-05-24 20:58 UTC, Lucas Rocha
committed Details | Review

Description Sebastien Bacher 2008-03-12 14:09:30 UTC
gnome-session needs to stop gnome-settings-daemon cleanly, at the moment it doesn't, esd is still using the sound device after logout and that breaks sound for the next logins
Comment 1 Bastien Nocera 2008-03-12 15:55:12 UTC
I think PulseAudio will exit properly in this case, as we make it load the x11 module, and it will exit as soon as the display is disconnected.

esd doesn't have such magic.
Comment 2 Rob Bradford 2008-04-03 20:43:39 UTC
So in #525859 I supply a patch that adds support for a "Stop" dbus method on g-s-d . However perhaps it would be better for g-s to emit signal a dbus signal "SessionOver". Processes can then listen for this signal and then use this to do cleanup and tidy themselves up before killing themselves.

This would be need to only emitted once we knew that the end of the session is imminent and that it could not be cancelled.

In the case of g-s-d, it can listen for this signal on the session bus and then use this to unload its modules and make peace with the world.

My only possible would be about ordering, what happens if something listening for this signal depends on g-s-d but g-s-d get the signal before they do and then it kills itself but the other processs breaks horribly.

Perhaps, because of g-s's special arrangement with g-s-d it should go out and stop it. In which case this "Stop" method is good.

On a related note the panel also needs to know when a logout is going on so that it can do various housekeeping.

The other option of course is to use XSMP but we're trying to avoid that.
Comment 3 Dan Winship 2008-04-03 21:25:05 UTC
> The other option of course is to use XSMP but we're trying to avoid that.

Sigh. OK, maybe we need to push to get EggSMClient-without-state-saving into gtk now, for apps that need logout notification but don't care about state saving, and worry about whether or not state-saving will ever happen later...

> My only possible would be about ordering, what happens if something listening
> for this signal depends on g-s-d but g-s-d get the signal before they do and
> then it kills itself but the other processs breaks horribly.

(new-)gnome-session tells XSMP clients to die in reverse order of how they started, so g-s-d would be one of the last things told to exit.

However, g-s-d doesn't need to actually kill *itself* when it gets the Stop/Die signal; the original bug report is about non-X-based processes that g-s-d starts. So g-s-d would get the "session ending" signal, and tell esd and whoever else that they need to exit now, but it could leave itself running until the X connection went away if it wanted.
Comment 4 William Jon McCann 2008-04-03 21:54:32 UTC
I don't think want g-s-d to be an XSMP client.  It has to work in he GDM greeter for example.  Since gnome-session starts g-s-d I think it is fine for it to stop it explicitly as well.  
Comment 5 Dan Winship 2008-04-03 22:28:17 UTC
(In reply to comment #4)
> I don't think want g-s-d to be an XSMP client.  It has to work in he GDM
> greeter for example.  Since gnome-session starts g-s-d I think it is fine for
> it to stop it explicitly as well.  

new-gnome-session does not explicitly start g-s-d, and has no special awareness of it; it starts g-s-d early in the login only because there is an autostart desktop file telling it to. One of the big goals of the gnome-session rewrite was to remove the 10 million special cases in gnome-session, and instead handle everything with generic, extensible, reusable mechanisms, so that, eg, when g-s-d has a bug like this, there will *already* a mechanism in place that would allow you to solve the problem yourself, without needing to file a gnome-session bug to get some new g-s-d-specific hack added.

In this case, the generic, extensible, reusable mechanism is supposed to be XSMP. If there are good arguments for not using XSMP in g-s-d, then, ok, but then the right solution is to find another generic mechanism, not to add a special case for g-s-d. Something like the generic "SessionOver" signal Rob suggested in comment #2 could work.

(I also suggested EggSMClient rather than GnomeClient because one of the goals of EggSMClient was to eventually support a simple D-Bus-based SM protocol in addition to the annoying XSMP-based one. So in that case, potentially gdm could be acting as a D-Bus-based session manager to EggSMClient-based apps. But that's off in the future anyway.)
Comment 6 William Jon McCann 2008-04-03 23:27:07 UTC
So, stepping back a bit.  I think that whatever solution we look for here needs to solve the case where the session is simply killed (ie. not just orderly logouts).  If I C-A-Backspace then gnome-session isn't going to help me here, right?

I think first thing we should do is make sure that gnome-settings-daemon is cleaning up all its children when it is signaled.  I doubt we do...

Hopefully the login session id will be exposed in /proc soon and we'll be able to kill the entire session from GDM.

Comment 7 Rob Bradford 2008-04-04 17:04:20 UTC
Sorry to muddy the waters entirely again here... but, I think perhaps we can solve this with process groups...but I need to look into that again... (trying to remember from University)

William, I guess we could register a signal handler for SIGTERM which the only thing it does is call g_main_loop_quit and then we can tidy up after that.

At the moment we are just getting killed and so none of our cleanup after the mainloop is happening.

But signal handlers scare me...i'll have a play and if I get it to work I will send a patch.

Thanks for the discussion guys!
Comment 8 Lucas Rocha 2008-04-08 17:35:44 UTC
This bug report is about exiting cleanly but we currently have some problems on session startup because it doesn't connect to session daemon anymore (i.e. EggSMClient or GnomeClient). I've made a proposal on bug #526984.
Comment 9 Jakub 'Livio' Rusinek 2008-04-20 17:44:19 UTC
for now pulseaudio is closed until end of played sound is reached.

gnome-session should first play sound and then start exiting procedure to prevent sound interrupting.
Comment 10 Lucas Rocha 2008-05-24 20:58:06 UTC
Created attachment 111482 [details] [review]
Make g-s-d listen to SessionOver D-Bus signal to exit cleanly on session end.

Now gnome-session emits a SessionOver D-Bus signal just before ending the session. This patch implements the g-s-d side. I've added a call to gnome_settings_manager_stop and gtk_main_quit on the callback but I'm not sure if this is what we really want.
Comment 11 Lucas Rocha 2008-05-24 20:58:35 UTC
Re-assigning this bug to g-s-d. 
Comment 12 Jens Granseuer 2008-05-26 19:45:40 UTC
Looks good to me. Please apply. We probably also need to deactivate all active plugins in gnome_settings_manager_stop to clean up externally started processes etc.
Comment 13 Lucas Rocha 2008-05-27 20:35:33 UTC
Commited in trunk, thanks!

2008-05-27  Lucas Rocha  <lucasr@gnome.org>

        * gnome-settings-daemon/main.c (set_session_over_handler,
        on_session_over, main): listen to "SessionOver" D-Bus signal from
        Session Manager to know when to shutdown. Bug #522017.