Hide Forgot
Created attachment 469810 [details] Proposed patch +++ This bug was initially created as a clone of Bug #630052 +++ Description/reproducer steps/additional info edited. Description of problem: gnome-session fails to save desktop sessions, incorrectly collapse apps from many workspaces into a single workspace, loses positional placements. Version-Release number of selected component (if applicable): gnome-session-2.28.0 (and later) How reproducible: Always Steps to Reproduce: 1. Enable metacity debugging by setting the env var "METACITY_VERBOSE=1 METACITY_USE_LOGFILE=1", for example using a script in /etc/profile.d/ 2. Log in in GNOME, start a few session managed applications on different workspaces, different positions 3. Make sure to enable saving sessions with "gnome-session-properties" by enabling "Automatically remember running applications when logging out" 3. End the GNOME session 4. Log in again in GNOME Actual results: All windows are restored on the first workspace and the initial position is not restored. Expected results: A saved session, apps restored to their original workspaces and correctly positionally placed. Additional info: I believe this is an upstream bug. What happens is that metacity uses the same session state file each time, named after the SM client-id which remains the same across sessions: SM: Phase 2 saveSM: Saving session to '/home/ofourdan/.config/metacity/sessions/10c1255ad91a092ac129198879916898400000020420025.ms' ... SM: Exiting at request of session manager The discard command is: :X-GNOME-Autostart-discard-exec=rm -f /home/ofourdan/.config/metacity/sessions/10c1255ad91a092ac129198879916898400000020420025.ms (this is in the desktop file for the session, as found in ~/.config/gnome-session/saved-session/*.desktop) So gnome-session removes the previous session state file saved by the applications after each application has saved its state but because metacity uses the same file, its state file is removed by the session manager and the state is not restored (thus the position and workspace of running windows is not restored): The problem appears with that commit upstream: http://git.gnome.org/browse/gnome-session/commit/?id=3e346957cebcbf9e747757d2d649329266743afc The order of events is as follow (observed by enabling debug logs in both metacity and gnome-session): 1. Session terminating 2. Session manager sends a SaveYourself to all clients 3. metacity gets the SaveYouself message, save its state file and replies SaveYourselfDone 4. Session manager gets SaveYourselfDone 5. Session manager checks for the given discard_exec command in hash table in gnome-session/gsm-session-save.c gsm_session_clear_one_client() 6. Session manager does not find the discard_exec in hash table so it runs the discard_exec command, thus removing the state-file in gnome-session/gsm-session-save.c gsm_session_clear_one_client() 7. Session manager adds the discard_exec to the hash table in save_one_client() So the discard command is never found in the hash (being empty) because the hash is populated after the removal... gsm_session_save() | +-> gsm_session_clear_saved_session() | | | +-> gsm_session_clear_one_client() | | | +-> g_hash_table_lookup (discard_hash, discard_exec) ? | FALSE => g_spawn_async (discard_exec) | +-> save_one_client() | +-> g_hash_table_insert (data->discard_hash, discard_exec, discard_exec); The patch here attached does the things differently, it actually populates the discard_hash with the existing (old) discard commands, then save the session and removes the old discard command only if not found in the hash. This way, if the old and new file are identical, the file is not removed by the session manager. With this patch, gnome-session and metacity behave as expected. It is also possible to change metacity (see the patch proposed in bug 643450) yet I think this is really a bug in the session manager (rather than metacity).
Will need to investigate more, but the explanation looks carefully researched and there's a patch. devack+
(In reply to comment #3) > Will need to investigate more, but the explanation looks carefully researched > and there's a patch. devack+ Is this the same patch attached to this bug report or is it some other patch still under test? In any case, can I have some instructions on how I can install this patch, step-by-step so I can get this folded into my F13, since it is now EOL or will there be a backport or release to fix this on F13?
This looks like a downstream bug, actually. We have a patch that does: data.discard_hash = g_hash_table_new_full (...); + gsm_session_clear_saved_session (..., data.discard_hash); gsm_store_foreach(..., save_one_client, &data); ... - gsm_session_clear_saved_session (..., data.discard_hash); So that's pretty wrong, and it's what's causing the behavior mentioned above: "So the discard command is never found in the hash (being empty) because the hash is populated after the removal..." from comment 0.
Okay, I've corrected the bug alluded to in comment 6 and am building packages now.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Prior to this update, the gnome-session utility may have improperly saved desktop sessions. As a consequence, when logging in, the running applications were incorrectly collapsed from multiple workspaces into the first workspace and their initial position was not restored. This has been fixed: applications are now restored in their original workspaces and correctly positionally placed.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2011-1654.html