Re: session management subtlety

[Matthias Ettrich <ettrich trolltech com>]

On Tuesday 27 November 2001 03:12, Havoc Pennington wrote:
> Hi,
>
> (This is a real bug in both desktops, but esoteric enough that I
> expect only SM authors to know what the hell I am talking about ;-)

Unfortunately I know what you are talking about ;)

>
> An interesting issue with both KDE and GNOME is that they use
> SaveYourselfRequest to signal a request for a logout. Both then offer
> a "save session" checkbox in the logout dialog.
>
> Here is the problem. Say I log in at 2 pm, save my session (but don't
> log out) at 3 pm, and then log out and do not save my session at 4 pm.

How do you save your session in KDE but don't log out? Isn't that quite 
esoteric? The only way to achieve this is to start logging out with save 
session checked and aborting the logout via some cancel button.

>
> The way the "do not save" checkbox works in both KDE and GNOME is that
> the session manager will not write its session file if you don't save
> your session. However, _applications_ are still sent SaveYourself, and
> still save their state.

In case you log out with "do not save" checked, the applications receive a 
SaveYourself with "Global" only. In other words: they might ask the user to 
save modified files, but they won't write anything in their session 
configuration.

>
> Assuming applications store their state per-session-ID, rather than
> per-SaveYourself, the result is that I would get the session file from
> 3pm, but the application states from 4pm. This means that e.g. I might
> get the wrong number of windows open for an app. The worst case
> scenario when getting the wrong number of windows is to get too few,
> because the window manager gets confused and restores session state to
> the next window the user opens manually. (This can result in fun stuff
> like the window manager maximizing a dialog.)

The window manager should have received a saveYourself message as well. If it 
stores its session data only tagged with the sessionId, it shouldn't matter 
if the session manager uses an old session file to restart the wm.

>
> This bug doesn't typically manifest when using gnome-session and GNOME
> apps, or ksmserver and KDE apps, for different reasons in each case.
>
> For KDE, AFAICT from tests with kwrite, the apps have the bug, in that
> they save their state per-session-ID rather than per-SaveYourself.
> That is, kwrite sets its RestartCommand to "kwrite -session
> 11c0a80002000100682637000000015610000" where the long string is the
> session ID. However, the bug doesn't occur because ksmserver does not
> allow the save at 3pm; it equates saving with logging out:
>
>     void KSMSaveYourselfRequestProc (
>         SmsConn             /* smsConn */,
>         SmPointer           /* managerData */,
>         int                 /* saveType */,
>         Bool                /* shutdown */,
>         int                 /* interactStyle */,
>         Bool                fast,
>         Bool                /* global */
>     )
>     {
>         the_server->shutdown( fast );
>     }
>
> (Ignoring the "global" flag here is really a bug IMO.) Anyway, with

Yes and no. The way a save yourself request works with ksmserver, is that it 
launches the ksmserver GUI, which again has the magic checkbox that makes it 
possible for the user to select. The default value depends on what the user 
did last time. But (of course...) this is configurable, so you might choose 
to run KDE without a logout confirmation dialog at all. In this case the 
user's predefined value for "global" will be used.

> gnome-session, kwrite would have the bug. It's possible that even the
> ksmserver/KDE-app combination has issues if you log out once and save,
> then log out again and don't save - maybe for session IDs present in
> both sessions you would get the app state from the second logout.
>
>
> GNOME apps by default use a randomly-generated string that is
> regenerated per-SaveYourself to record their session state - I don't
> know if this is a deliberate response to this issue, or just dumb
> luck. So e.g. "gless" sets a RestartCommand like:
>  gless --sm-config-prefix /gless-y0tFYm/
> This means that GNOME apps using the usual setup will always get back
> the state associated with a given SaveYourself. However, there is no
> real requirement in the SM spec that apps are "safe" against the
> session manager in this way.

My first implementation had something similar. I wasn't using a random 
string, but some additional counter. So there wasn't only a session id per 
application, but also a reincarnation id within that session.  I also wanted 
to make it possible to login into session "Work", and eventually save what 
you have as session "Work2", with "Work" still being available. 

My feeling back then was that it got too complicated, and that programmers 
and users had enough trouble already understanding session management 
(especially the local mode) as it was.

But it really is a bug in the protocol. The easiest and cleanest solution 
would be that a saveYourself message featured a new session id for the 
client.

>
> Anyhow, there are two possible fixes I can see. One is to require that
> session managers always record the latest RestartCommand of any app
> that has received a SaveYourself. i.e. the SM must save to disk if the
> app saves to disk. 

This sounds like the right suggestion for the time being. In order to be able 
to implement it, I'd like to know how you achieved the situation in question 
with ksmserver (other than a cancelled shutdown).

> The other is to require that apps save state
> per-SaveYourself, not per-session ID. In either case, I think
> documenting the clarified behavior would be a good idea.

The third possibility might actually be to extend the protocol to send 
clients a new session ID in the save yourself message.


Matthias

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers