GNOME Bugzilla – Bug 144107
window manager should be killed last when logging out
Last modified: 2021-06-14 18:21:07 UTC
when one logs out of gnome, metacity is killed before other processes, so that one gets to see all currently opened windows on all workspaces collapse on top of each other without their decorations and such. That looks pretty like something broke. I guess gnome-session does know which process is the window manager, so it can wait for other process to die before killing it.
I agree, we should be smarter about this. We should also be smarter about startup ordering.
Created attachment 78746 [details] [review] Proposed patch This patch ensures that the clients are removed from the session in the opposite order they were added to it (like a stack). I hope the quick hack is readable enough, we could also explicitly iterate over the list, but then the REMOVE statement would look a bit fishy.
(You could simply reverse the list instead... (Useless O(n) vs. O(n^2) optimization ;-) ) I can't test the patch, but: doesn't that simply remove the items from the list of clients in the session (as opposed to actually killing them)? I don't know where the client list is gotten from, but one has to keep in mind that the window manager may have changed since gnome-session started it, so one may need to see who owns the WM_S<screen-numeber> selections (for each screen?) to see what processes are window managers. I think.
(In reply to comment #3) > I don't know where the client list is gotten from, but one has to keep in mind > that the window manager may have changed since gnome-session started it, so one > may need to see who owns the WM_S<screen-numeber> selections (for each screen?) > to see what processes are window managers. I think. Ew. Don't do that. Just sort the list in reverse order of _GSM_Priority property values.
I'm really not sure how this can be handled properly. We seem to have three possibilities: * Remove the clients in the reverse order they were added to the list * Remove the clients in the reverse priority order, i.e. remove those first that have a higher priority score, which means they are supposed to be started later * Use/introduce some mechanism that makes us aware about session-launched and user-launched clients, and may also provide info about the purpose of the apps to determine the order and remove the clients that were launched by the user first The first possibility has the problem that a WM that was launched during the session and appended to the list won't be removed last. I think it would be a good idea to use the second option as suggested by Dan, and tell WM authors to set the GsmPriority to the smallest possible value. Marking patch as "rejected".
Created attachment 79512 [details] [review] sort list before sending die message Please try this patch. It reverse sorts the list of clients before sending the 'die' messages.
Tom: I'd prefer save_finished_list = g_slist_reverse (g_slist_sort (save_finished_list, compare_priority)); It doesn't add so much clutter. Thanks for looking into it, though :).
Created attachment 79546 [details] [review] patch updated to reflect comments How about this one?
Great! I've mailed the desktop development mailing list. Now we just need a maintainer to approve it :). Setting version/priority/severity information.
Tom: if it works as expected, just go ahead and commit :-)
This sounds really cool. I've tested the patch, but it does not always work, still leaving some windows "naked" (i.e. without decoration) on logout. Anyways, the behaviour is better than the one we currently have. From a brief look at the code: SmsDie (client->connection) is being run on all apps in the list. Is that a blocking call? If not, we might end up that metacity shuts down before the last application and its window(s) vanishes.
I checked in my patch. SmsDie is blocking on the server side, but of course clients may take different amounts of time to respond to a message. The only way to make shutdown really synchronous would be to send SmsDie and then wait for the corresponding channel to be closed. I suppose this could be done if there is a timeout. But I'm concerned that this would make the overall shutdown slower. Maybe a small timeout would work. This is related to the PR about startup ordering.
Change the version to 2.22.0.
Even if we blocked on SmsDie calls, which would, as Tom mentioned, be really horribly slow, there's still going to be a problem with non-session-managed apps, which won't be told to Die at all, before or after the window manager. At this point, I think the right fix is that metacity should just ignore the "Die" request from the SM, and keep running until it's killed by losing its X connection. That ensures it will not exit while any other app is visible. Right?
*** Bug 529036 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > At this point, I think the right fix is that metacity should just ignore the > "Die" request from the SM, and keep running until it's killed by losing its X > connection. That ensures it will not exit while any other app is visible. > > Right? Wrong. I changed my mind on this one. If the SM tells an XSMP client to Die, the client should die. Also, we want the right thing to happen if the user is using a different window manager as well. One fix would be for gnome-session to just not kill apps in the Initialization and WindowManager (and Panel?) phases, and let them be killed by X exiting instead. But then, that would probably interfere with bug 522017 (making g-s-d exit cleanly). But we could use the suggestion from there of having a d-bus signal... So in that case, logout would look like this: - User selects "Logout", clicks "OK", whatever - gnome-session tells all post-WM-phase apps to Die - XSMP client apps exit. Non-XSMP apps are still running, but so are metacity and gnome-settings-daemon, so everything still looks ok. - gnome-session emits a "logging-out" d-bus signal - gnome-settings-daemon gets the d-bus signal, and tells some of its child processes (like esd) to exit, but *does not exit itself* - gnome-session exits - gdm bounces the X connection, causing metacity, gnome-settings-daemon, and all the non-XSMP apps to die simultaneously
everywhere you said "metacity" insert "window manager" instead, and everywhere you said "esd" put "pulseaudio", to be modern :> . PS: please change the summary appropriately and change the version of gnome-session and gnome itself.
(In reply to comment #17) > everywhere you said "metacity" insert "window manager" instead, and everywhere > you said "esd" put "pulseaudio", to be modern :> . actually, pulseaudio doesn't have the problem, only esd does :)
pulseaudio is killed until end of sound is reached.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version of gnome-session, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-session/-/issues/ Thank you for your understanding and your help.