I can confirm this bug on Fedora Core 5 with all the latest updates. In my case, I'm trying to save a session with multiple xterms and upon logout/login only one remains and it has the wrong colors and font. This problem did not exist in FC4, but I have confirmed it for gnome-session 2.14.1 and 2.15.1. I have installed metacity from CVS HEAD (as of 2006-06-02), which includes a patch so that metacity no longer coredumps on logout, but sessions are still not restored, so I suspect it's a problem with gnome-session.

The thread at http://www.redhat.com/archives/rhl-devel-list/2006-February/msg01194.html also
talks about GNOME sessions not being restored properly. Different symptoms but maybe same cause?

I can confirm this bug on FreeBSD. I'm running gnome-session 2.14.2, but this has existed since upgrading to 2.14.

I have a similar problem, but I'm not sure it is the same.  With Fedora Core 5, I have a gnome session with five large terminal windows in different workspaces, and nothing else.  If I reboot, this session is restored just fine.  But if I have a crash it is not restored.  Instead, I get a session with the correct gnome-panel but only one terminal, a small one, in one workspace, and, in addition the Nautilus file manager, which I don't want.

I may be able to work around this problem by putting gnome-save-session in my session startup programs.

But, it seems to me that, after a crash, the gnome session should still be the same one that was used at the last boot.  Somehow, it is not.

This problem also happens if I use gdm-restart, rather than a crash.

Could it be a gdm problem instead of a gnome-session problem?

Because may be gnome-session has no time to save data upon exit...

(In reply to comment #5)
> Could it be a gdm problem instead of a gnome-session problem?
> Because may be gnome-session has no time to save data upon exit...

I think it is both gdm and gnome-session.  Gdm seems to be looking for a session and finding it - somewhere [I wish I knew] - instead of the last session that gnome-session saved.  It may be that gnome-session is deleting that session record.  If not, why doesn't gdm find it when gdm restarts?  If you have gnome set to "save session on exit," then it DOES save the session when you log out.  But when it crashes the session from the PREVIOUS session is apparently gone. I'm just guessing.  I cannot find any documentation about where these sessions are stored.

Session information seems to be kept in ~/.gnome2/session and in ~/.metacity/sessions/<some-long-id>.ms. From what I can tell, session info is *saved* correctly in these files (e.g., when doing "gnome-session-save"), just *restoring* the saved session on the next login isn't working.

(In reply to comment #7)
> Session information seems to be kept in ~/.gnome2/session and in
> ~/.metacity/sessions/<some-long-id>.ms. From what I can tell, session info is
> *saved* correctly in these files (e.g., when doing "gnome-session-save"), just
> *restoring* the saved session on the next login isn't working.
> 

The problem I had was different.  Gnome-session-save did indeed work as it was supposed to work, so, even after a crash, I could restore the session that was saved, IF I had saved it with gnome-session-save.  But if I did NOT use gnome-session-save, then, after a crash or after gdm-restart, the session was something that I never intended.  I would think I would get the last session that I had saved, or the last session that I had correctly logged out of, but that did not happen.  The restored session was coming from somewhere else.  So it seems  that the session saved by gnome-session-save does not persist in a usable form beyond the NEXT time gnome starts up.  The time AFTER that, it is apparently gone.

*** Bug 343701 has been marked as a duplicate of this bug. ***

This is caused by bad interaction between the old session management and the new autostart code. If you add something to the autostart list, and then save your session, you'll end up having that program listed in both the autostart list and in the session file. So gnome-session copes with this by removing duplicates. But it's doing it overzealously in this case.

Removing duplicates sounds pretty scary.

I've been thinking about a different approach to saving and restoring
sessions, inspired by Havoc's posts to the desktop-devel list.

For the GUI we would simply present an autostart folder, say in nautilus.
Its contents would be computed by following the XDG autostart spec --
eg if a desktop entry is hidden by some later file, it would not appear.

The user could then edit this by dragging and dropping.  When removing
special entries (daemons, or metacity, etc -- these could be marked with
a special flag in the desktop file), we would show a dialog asking whether
the user really knows what he's doing.

We would also have a button or menu item somewhere saying "save these
windows".  This would populate the autostart directory based on the
current session.  A session's saved form would just be this collection
of .desktop files.  We'd extend the XSMP spec a little so that apps could
upload their entire .desktop file.  (This step lets us continue to support
power users who want to have a default session with 4 gnome-terminals or
whatever...)

We'd get rid of multiple named sessions.  And we'd hide the save-automatically
feature (or perhaps even remove it entirely).

Gnome applications also wouldn't use clone commands, discard commands, resign
commands, or shutdown commands.  We'd leave some minimal support for this
in gnome-session, though.

(In reply to comment #10)

OK, so right now, if there are any two items with the same argv[0], all of
them after the first get removed. The goal of duplicate-removal is to fix
the case where an app is listed as autostarted, but has also been XSMP
saved; you only want to start the XSMP-saved version of the app in that
case. So the correct duplicate-removal behavior is:

  1. Only XSMP-resumed items (ie, clients with a match_rule of MATCH_ID)
     trigger duplicate-removal
  2. Only autostarted items (clients with match_rule of MATCH_PROPS)
     are victims of duplicate-removal

So if you have two autostarted gkrellm2s, neither should be removed, because
they're both autostarted, and autostarted apps don't trigger duplicate
removal. Likewise, if you have two XSMP-saved gkrellm2s (and no autostarted
ones), neither should be removed, because XSMP-saved apps never get
duplicate-removed. But if you have both an autostarted gkrellm2 *and* an
XSMP-saved gkrellm2, then the XSMP-saved one should cause the autostarted one
to be removed from the list, leaving you with just the XSMP-saved one, which
is what you want.

If you have two autostarted gkrellm2s and only one XSMP-saved one, then this
algorithm would cause *both* autostarted gkrellm2s to be pruned and only the
single XSMP-saved one to be started. But in fact, that's the correct behavior
as well: the only way you could have two autostarted gkrellm2s and end up with
only one XSMP-saved one would be if you had quit one of the two gkrellm2s
before saving the session, and so it is correct to only start up that one when
resuming the session.

*** Bug 434842 has been marked as a duplicate of this bug. ***

Hi, I'm one of the people behind the bug just marked as a duplicate of this one.
Reading comment #12 it seems this is fixable without major surgery. I'm pretty fluent at C, so I might take a stab at this, where / how do I find out what the match_rule of a client is, or will that be self explanatory once one dives into the code?

The function you want to look at is remove_duplicated_clients() in
gnome-session/save.c. (Yes, the session LOADING code is in "save.c". So much
for "self-explanatory" :-) It iterates through the list of "Client" structures,
and "match_rule" is a field in Client.

Created attachment 88017 [details] [review]
PATCH fixing this using the methoded described in comment 12

Here is a patch fixing this as described in comment #12

I've tested this and now I can save a session with multiple xterms open, and then when it restores get them all back, hurray!

However I have 3 xterms in my startup list, but due to this bug my saved session had only 1, even with this new code, all 3 xterms from my startup got removed as duplicates for this 1 in my saved session. A potential fix is to stop looking for duplicates once one is found, this is as simple as adding a single break statement. But I'm not sure this is pretty.

I think the current version of my patch, which just removes all identical startup entries if there is an identical entry in the saved session is better, because there is no way to know which entry to remove. If for example in the startup there are 2 gkrellm starts, with 2 different configs selected through cmdline args, which one should be removed?

Notice that this patch also fixes the hack, where the starting for duplicates is restarted whenever one is removed from the list. It does this by using a while instead of a for, and making the iterating pointer, point to the next member before removing the current member from the list (if any removal happens at all).

(In reply to comment #16)
> However I have 3 xterms in my startup list, but due to this bug my saved
> session had only 1, even with this new code, all 3 xterms from my startup got
> removed as duplicates for this 1 in my saved session.

remove_duplicated_clients() is run when *restoring* the session, not when
saving it. If your current session file has only one xterm listed, it's
because you saved your session at a time when you were running only one
xterm. (Probably you saved it once, then resumed it, and the bug caused two
of the xterms to be removed, and then you saved it again?) So I think the
patch is correct without the break and you just need to fix your existing
saved session.

(I'm not a gnome-session maintainer, so you'll have to wait for someone else
to accept or reject the patch though.)

(In reply to comment #17)
> (In reply to comment #16)
> > However I have 3 xterms in my startup list, but due to this bug my saved
> > session had only 1, even with this new code, all 3 xterms from my startup got
> > removed as duplicates for this 1 in my saved session.
> 
> remove_duplicated_clients() is run when *restoring* the session, not when
> saving it. If your current session file has only one xterm listed, it's
> because you saved your session at a time when you were running only one
> xterm. 
Correct

> (Probably you saved it once, then resumed it, and the bug caused two
> of the xterms to be removed, and then you saved it again?)

Correct.

> So I think the
> patch is correct without the break and you just need to fix your existing
> saved session.
>
Ok
 
> (I'm not a gnome-session maintainer, so you'll have to wait for someone else
> to accept or reject the patch though.)
> 

Anything special I need todo to get the attention of a gnome-session maintainer?

This looks okay, so I committed it. If Tom or Mark or anyone who know more than me about session management feel it's wrong, they'll speak up :-)

It's better than what we currently have, but I guess it's not perfect since it can't really guess what the user would expect: the information we have is not complete enough for this. Sometimes, it should not remove all autostarted duplicates while sometimes it should. But we can't fix this.

Thanks!