Subject: Re: FVWM: fvwm-2.0.43 under Digital Unix 4.0: does not die properly when X server dies....

From: Thomas Leitner <[email-masked]>
Date: Fri, 30 Aug 1996 22:21:26 +0200 (MET DST)

Hi Jeff,

On Fri, 30 Aug 1996, Jeff Magill wrote:

> > Now when I just terminate the session,
> >by stopping the dxsession manager (which causes the X server to die),
> >I can see 'fvwm2' and 'FvwmButtons' still running and eating CPU time
> >when I log-in from a remote terminal.
> 
> I guess you're cutting the X server out from underneath fvwm2.

Yes. Apparently.

> I think usually people exit their X server the other way around.  That is,
> the X server is usually dependent upon some application still
> running--usually the window manager.
> 
> For example, I use xinit to start my X server.  xinit fires of a shell
> script, .xinitrc, that fires up fvwm2 and some other applications.  When
> .xinitrc exits, then the X server shuts down.  My .xinitrc script waits
> until fvwm2 exits and then it exits.  So when I exit fvwm2 explicitly
> (using the Quit function), the .xinitrc script notices that the window
> manager has quit and then it exits.  Then the X server shuts down.

Well. I do it like this:

   a.) The X Server is started
   b.) dtlogin is started and I log-in selecting dxsession
   c.) dxsession starts up and I've configured it to use
       /usr/lib/X11/fvwm2/fvwm2 rather than /usr/bin/X11/mwm.
   d.) dxsession executes the .X11Startup file to startup my
       initial apps.

When I want to log-out, I use the dxsession's logout command which
apparently causes the x-server to die without fvwm2 noticeing.

Please note that this works without problems when I select the
standard Motif Window manager. It also worked without problems
using fvwm-1.24r

What can I do about it? I mean: What happens if the X server dies
for other reasons in your configuration? Then you run into the same
problems and fvwm2 will eat up CPU time as well. I think that fvwm
should just die when the X server died.

Thanks for your reply -- Tom

--------------------------------------------------------------------------
T o m   L e i t n e r                       Dept. of Communications
                                            Graz University of Technology, 
e-mail    : [email-masked]      Inffeldgasse 12
Phone     : +43-316-873-7455                A-8010 Graz / Austria / Europe
Fax       : +43-316-463-697
Home page : http://wiis.tu-graz.ac.at/people/tom.html
PGP public key on : ftp://wiis.tu-graz.ac.at/pgp-keys/tom.asc or send 
mail with subject "get Thomas Leitner" to [email-masked]
--------------------------------------------------------------------------

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

---

From: Grant McDorman <[email-masked]>
Date: Fri, 30 Aug 1996 16:33:02 -0400 (EDT)

One problem with FvwmButtons is that in its cleanup code it does
   signal(SIG_PIPE, SIG_IGN);
and then tries to communicate with the server. If the server connection has
been broken - as in the case here - this results in FvwmButtons going into
a tight CPU-consuming loop [at least on my platform, Sun Solaris 2.4].

This sort of server shutdown/reset also happens on multiscreen displays,
which is how I found it. I have made a change to FvwmButtons to try and
fix this problem (by changing the signal handling to 'exit' instead of
SIG_IGN). I haven't checked to see if other Fvwm modules, or the main
code, has this problem too, though. I also haven't posted the change
to list [yet].

Just checked fvwm itself; it may have this problem too, since it
installs a signal handler (DeadPipe) which, in effect, ignores
the signal (it just reinstalls itself). Problem is, of course, that
fvwm *can* get SIGPIPE signals that it is legitimate to ignore (when
communicating with a module). If the code can check to see if the X
server (connection) is dead in the signal handler, and exit() if it
isn't, then the problem may disappear. Something like:
   struct stat buf;
   if (fstat(XConnectionNumber(dpy), &buf) == -1) exit(1);
(assuming 'struct stat' and 'fstat' are, in this usage, 100% portable,
*and* presuming fstat returns -1 on a dead, but not closed, pipe.)

I'll try this out shortly (oh, the joys of XNest).

> Thanks for your reply -- Tom
Grant McDorman <[email-masked]>
				ISG Technologies, Inc.

---

From: Thomas Leitner <[email-masked]>
Date: Sat, 31 Aug 1996 10:11:25 +0200 (MET DST)

Hi Grant,

> code, has this problem too, though. I also haven't posted the change

[...]

If your change is working, I'd appreciate if you could post it to the
list together with the change for fvwm itself.

Thanks a lot for your answer -- Tom