Subject: session management problems

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 15 Mar 2001 05:24:56 -0600

Here is a list of known remaining SM problems.
I think some of them are features, they are not critical for 2.4.0.
But the ones marked by '-' at the end could probably be fixed.
Tell me if you want me to explain/investigate something more deeply.

* SaveSession/QuitSession don't work in xsm, I don't know what to do.
Works satisfactory with gnome-session. It is documented in the man page.

* There is an old known problem with swallowed windows, they multiply
on every start. The solution is not to use swallowing button bars,
or, maybe, to use session aware programs (xload and xclock are not)
and mark them "Restart never" if possible.

Teoretically using Swallow(UseOld,NoClose) should help, but it does not
(probably because FvwmButtons starts before old xload/xclock).
It even produces walking windows before reswalowing on restart,
see other entries. They appear for 5 seconds and then are swallowed.

I thought about a new Swallow(AllowOnlyOne) option especially for SM,
which kills all application instances except for one.

* Some freeze of 5 seconds on Restart with some configurations, supposedly
with Swallow(UseOld,NoClose). I didn't have time to investigate this.

* I can't find whether it is possible to define application priorities in
xsm. GNOME deskguide_applet is started before fvwm, so it pop ups a window
"No GNOME compliant WM" every time. There are priorities in gnome-session.

* xsm sometimes exits with no core when clicking on "Client List".
This sometimes is autosolved, but sometimes is not. The solution is
to delete this session and start a new one... I can't debug xsm.

* If a new FVWM crashes while restarting in SM, a session manager will
try to start FVWM forever. FVWM itself asks for this. Probably there is
nothing to do about this.

* If state file is not used on Restart (because version don't match or
not found), windows without -geometry walk. On fvwm's Quit the client
windows remain in the same positions, not in the frame possitions.
I would like to know why is it.

- All windows on the not current desks become iconic after Restart.
Seems that I can reproduce this consistently with xsm.

- I can still get incorrect IS_NAME_CHANGED 0 when saving a window state.
The debug output on the matching time is:

        win(xterm, XTerm, xterm, 0)
[0]     mat(xterm, XTerm, migo@sparta, 0)

when it should be:

        win(xterm, XTerm, xterm, 0)
[1]     mat(xterm, XTerm, migo@sparta, 1)

Regards,
Mikhael.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Tue, 20 Mar 2001 03:32:49 +0100

>From the man page:

  Causes a session manager (if any) to save the session.  This command
  does not work for xsm, it seems that xsm does not implement this
  functionality.  Use Unix signals to manage xsm remotely.

Couldn't this be done as an option to the command, or is it
too difficult to find the pid of xsm?

> which kills all application instances except for one.

Hm, where is the problem?  Will this happen too if you put

  AddToFunction ExitFunc I KillModule *

into your config file?

> with Swallow(UseOld,NoClose). I didn't have time to investigate this.

That sounds like one of these obnoxious pointer grabbing issues.
Could you give me some instructions how to set up xsm and a config
file that shows the problem?

> "No GNOME compliant WM" every time. There are priorities in gnome-session.

Doh.  I wouldn't spend much time into this but rather document it
as a known problem.

> to delete this session and start a new one... I can't debug xsm.

Hm.

> nothing to do about this.

We could compare the file's read time vs it's modification time
and delete the file if these differ.  Of course this opens a new
can of worms, but xsm will at least not loop forever.

> not found), windows without -geometry walk.

Can you give me a hint how this can happen?  I vaguely remember
hacking up some test for this, but I don't know what exactly has
to happen to trigger that.

> On fvwm's Quit the client

That's because the ICCCM2 demands that clients with unmapped
frames are unmapped too.  It explicitly states that these windows
look as if they were iconified to the application.  Perhaps it
would be better to back out these patches since nobody seems to
take this part of the ICCCM2 seriously.  There is a related
problem with some applications thinking they have been iconified
when they are unmapped because of a desk switch.

> [1]     mat(xterm, XTerm, migo@sparta, 1)

How?  Is there any reliable way to cause this?  Try to add a debug
message at all places where this flag is set.  

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 21 Mar 2001 05:36:29 -0600

>   functionality.  Use Unix signals to manage xsm remotely.

Yes, I wrote this, it would be nice if someone confirm the xsm part.

> too difficult to find the pid of xsm?

I don't know how to find the pid of xsm even if it runs locally.

There is a code that parses session manager pid from $SESSION_MANAGER,
which looks like "local/sparta:/tmp/.ICE-unix/2725,tcp/sparta:1050";
the pid is 2725. But sending signals may only work if xsm and fvwm are
run on the same machine by the same user. I may only imagine what happens
if they are run on different machines and how $SESSION_MANAGER looks.

>   AddToFunction ExitFunc I KillModule *

It does not matter what fvwm does. xsm will start xclock/xload just
because they were running when a session was previously saved. So, if
FvwmButtons is started first there will be 2 (then 3) xclocks/xloads.

My suggested Swallow(AllowOnlyOne) only closes all other instances of
xclock/xload, but does not solve the problem that they are started twice
(once by FvwmButtons and once by xsm).

> file that shows the problem?

Please ignore this problem.

I tested using my old config and using fvwm-themes. I noticed that it runs
with fvwm-themes much better. By examining my old config I have found:

  *FvwmThemeColorset 15 YGradient 2400 2 blue 50 green 50 blue

Since fvwm and FvwmThemes behave as on process there is a freeze here.

----

As for setting up xsm, just run it instead of fvwm in .xinitrc.
It is also suggested to export SESSION_MANAGER_NAME=xsm to enable fvwm
workaround of xsm bug (I don't know about a better way to detect xsm).

Also I suggest to create ~/.xsmstartup with 2 lines, smproxy and
exec xterm (or exec fvwm2 -f myrc). I didn't test without smproxy running.

After you start xsm, choose "Fail Safe" start, open any applications you
want, don't forget fvwm, then press "Checkpoint", and name your session.

> Doh.  I wouldn't spend much time into this but rather document it

I didn't plan to do otherwise.

> > to delete this session and start a new one... I can't debug xsm.

This really makes xsm useless (at least my version from XFree86-4.0.1).

> can of worms, but xsm will at least not loop forever.

No, deleting state file will not help. xsm starts fvwm, not other way.
So if fvwm crushes before it changes its "(re)start in SM" info using XSMP
there is nothing to be done here, it will be restarted forever.
This is only a theotetical problem. The solution is to fix all crashes. :)

> to happen to trigger that.

You may set a different static version in get_version_string() or
uncomment the previous automatic version string. Then restart to a new
fvwm with a new version string.

> when they are unmapped because of a desk switch.

Ok.  I should say this is very inconvenient.
I don't really understand the mechanism, but can fvwm store a flag about
such windows and then remap them on the next start/match?

> message at all places where this flag is set.  

This is probably a feature after all.

The problem is that fvwm and xterm are started asynchronously, so there
are 4 cases of what fvwm sees about xterm in two runs.

Here is how it usually happens. xterm starts for the first time, it
changes its name, then fvwm is started, say for the first time. This
explains IS_NAME_CHANGED 0. Then the session is saved. On the next start
fvwm does not match this xterm entry as shown above. But now fvwm does
detect a name change and if the session is saved again, there is a hope
that for the next start fvwm will start first and xterm will match.

I withdraw this problem, since I don't see how it can be fixed.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 21 Mar 2001 14:45:49 +0100

> fvwm with a new version string.

I will take care of this problem.

> such windows and then remap them on the next start/match?

Actually, I'm more fond of removing that whole logic altogether.
I don't like the idea of preserving more information about iconic
state over restarts because the code already fails in some
situations.

> I withdraw this problem, since I don't see how it can be fixed.

The condition in the code looks like this:

  IS_NAME_CHANGED(w) || IS_NAME_CHANGED(m) || xstreq(...)

Wouldn't this be better:

  IS_NAME_CHANGED(w) || (IS_NAME_CHANGED(m) && !IS_NAME_CHANGED(w)) || xstreq(...)

Furthermore it might be good not to set the flag in events.c if
the name did not really change when a XA_WM_NAME property notify
arrives.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, email: [email-masked]
LifeBits Aktiengesellschaft, Albrechtstr. 9, D-72072 Tuebingen
fon: ++49 (0) 7071/7965-0, fax: ++49 (0) 7071/7965-20
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Wed, 21 Mar 2001 13:54:31 +0000

>   IS_NAME_CHANGED(w) || (IS_NAME_CHANGED(m) && !IS_NAME_CHANGED(w)) || xstreq(...)

These two lines look the same to me, are you sure it's what you meant?

Cheers,
Tim.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 21 Mar 2001 15:06:31 +0100

> These two lines look the same to me, are you sure it's what you meant?

No, what I wanted to say was that if both, m and w have the flag
set, the condition should be false, i.e.

  IS_NAME_CHANGED(w) != IS_NAME_CHANGED(m) || xstreq(...)

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Wed, 21 Mar 2001 08:17:22 -0600

>   IS_NAME_CHANGED(w) || (IS_NAME_CHANGED(m) && !IS_NAME_CHANGED(w)) || xstreq(...)

Depends on the reason the window changed name, if name is changed from
the $prompt shell's variable, it is better to ignore a name completely,
because it may be random. This new condition matches in even less cases
than the current one, so it will not really help with the problem above.

> the name did not really change when a XA_WM_NAME property notify

This is not related to my case, but I think that setting the flag is good,
so if fvwm did not get the first name change it will set it on the second.

I think the current meaning of IS_NAME_CHANGED is "application changes its
name, so we don't rely on it on matching".

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 21 Mar 2001 15:24:06 +0100

> fvwm with a new version string.

Fixed.  I hope that switching to desk 0, page 0 0 does not hurt
before restarting with xsm.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 21 Mar 2001 15:32:12 +0100

> than the current one, so it will not really help with the problem above.

Ah, I misinterpreted that.  I thought the flag was set too often.
SOmehow I was thinking this was about the IS_ICON_MOVED flag.

> so if fvwm did not get the first name change it will set it on the second.

Yes, you are right.  I'm not eager about writing any code for that
anyway.  Not with the I18N patch looking like it does right now.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 22 Mar 2001 03:29:13 +0100

> such windows and then remap them on the next start/match?

I disabled said patches, so this problem should go away.  I did
not test it yet, though.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 24 Mar 2001 17:52:29 +0100

> Works satisfactory with gnome-session. It is documented in the man page.

I looked at the xsm source code and it does indeed look as if xsm
does not implement that functionality (although my knowledge about
session management is verly limited).

> (probably because FvwmButtons starts before old xload/xclock).

I guess FvwmButtons has to communicate with the session manager
that these windows need not be restarted.  But let's postpone this
until after the 2.4 release.  BTW, xsm seems to restart my
xosview with the wrong command line options.  When I start it, I
only get the load, memory and paging meter, but when xsm restarts
it it gets the full set of meters :-P

Bye

Dominik ^_^  ^_^

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 24 Mar 2001 11:41:23 -0600

> it it gets the full set of meters :-P

You can enter "Client List" to see which xosview command line arguments
are used. I didn't get problems with preserving command lines. I run
smproxy.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 28 Mar 2001 02:48:15 +0200

On Sat, Mar 24, 2001 at 11:41:23AM -0600, Mikhael Goikhman wrote:
> are used. I didn't get problems with preserving command lines.

The other commands look good, but xosview is restarted without any
parameters.  The number of arguments in the RestartCommand section
is 1.

> I run smproxy.

I too.

Bye

Dominik ^_^  ^_^