Subject: FVWM2 cleanup patch

From: Sidik Isani <[email-masked]>
Date: Sun, 23 Sep 2001 15:41:35 -1000 (HST)

We've been using the fvwm-1.24r for years with the following patch
  to prevent clean-up problems when users log out.  The problem was
  sometimes users start things from their window manager menus which
  are not intended to be daemons, but also do not launch any windows,
  or the windows do not respond to the right signals to clean up when
  fvwm2 exits.  At the very least, we frequently were left with bogus
  processes still running, and in the worst cases, the X greeter would
  not restart.  Maybe someone else understands this better, but simply
  having the window manager try to clean up all its child processes
  when it exits (not restarts) has worked quite well:

diff -ru fvwm-snap-20010916/fvwm/fvwm.c fvwm-2.5.0-cfht/fvwm/fvwm.c
--- fvwm-snap-20010916/fvwm/fvwm.c	Fri Sep 14 01:00:07 2001
+++ fvwm-2.5.0-cfht/fvwm/fvwm.c	Tue Sep 18 19:55:12 2001
@@ -1675,6 +1675,17 @@
    */
   ClosePipes();
 
+  /* Any processes which FVWM started should also exit now, if they are
+   * still running in the same process group.  Any program that wants to
+   * continue running after the user's window manager session is gone
+   * should create its own process group.
+   */
+  signal(SIGHUP, SIG_IGN);
+  signal(SIGTERM, SIG_IGN);
+  kill(0, SIGHUP);
+  sleep(4);
+  kill(0, SIGTERM);
+
   exit(0);
 }
 
--
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: Mon, 24 Sep 2001 11:20:39 +0200

> +++ fvwm-2.5.0-cfht/fvwm/fvwm.c	Tue Sep 18 19:55:12 2001

That patch may cause a lot of trouble if X does not exit when fvwm
does.  For example, I often have these two lines near the end of my
.xinitrc:

  # start fvwm without any config file
  fvwm2 -f /dev/null
  # fall back to normal config file after exiting
  fvwm2

Also, this fails miserably if you restart fvwm in the mean time
since the new fvwm process does not become the parent of the
windows.  Neither does it help if windows are started from outside
of fvwm, e.g. from .xinitrc.  Why don't you simply do this in
.xinitrc?  For example, since netscape often hangs, I have

  killall -15 netscape

as the last line.  I'd only do this for applications that tend to
hang, not 

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: Sidik Isani <[email-masked]>
Date: Mon, 24 Sep 2001 14:10:23 -1000 (HST)

Hello Dominik -

  Regarding the clean-up patch I posted:  Given the way you illustrate
  going from one window manager to another (with the xinitrc), it's
  clear that you'd want it to be optional, or don't include it at all.
  Indeed you can do almost the same thing from the xinitrc, but it is
  considerably more complex that way ...

|That patch may cause a lot of trouble if X does not exit when fvwm
|does.  For example, I often have these two lines near the end of my
|.xinitrc:
|
|  # start fvwm without any config file
|  fvwm2 -f /dev/null
|  # fall back to normal config file after exiting
|  fvwm2

  Well, the behavior would be all processes launched by the first
  fvwm2 would be cleaned up before the second fvwm2 starts.
  Maybe not what you wanted, but note that things do work fine if
  fvwm2 is used to restart itself or another window manager instead.

|Also, this fails miserably if you restart fvwm in the mean time
|since the new fvwm process does not become the parent of the

  Actually it does work.  When you restart, fvwm2 exec()'s itself
  or a new window manager.  Either way, its PID stays the same and
  all windows launched since the beginning of the session remain
  child processes (which are reached by the kill(0, ...)).

  The whole concept isn't even that non-standard.  If you launch a
  bunch of stuff from a terminal and then close that window, all
  the processes in the group see a SIGHUP too.  (So it's not a
  wrong or bad way to shut down programs.  They all expect it, or
  they will detach from the terminal so they won't see this signal.)
  The feature just brings that simple but effective concept for
  terminal sessions up to a window session.

|windows.  Neither does it help if windows are started from outside
|of fvwm, e.g. from .xinitrc.  Why don't you simply do this in

  The way our xinitrc's are set up, it does.  The last thing xinitrc
  does is "exec fvwm2".  fvwm2 nicely inherits any clients already
  started by the xinitrc.

|.xinitrc?  For example, since netscape often hangs, I have
|
|  killall -15 netscape

  That would kill a netscape I have running on another X-Terminal
  in another room.  Not good.

  And some of our machines don't have killall.  But even with
  grep/awk junk in our scripts, the list was getting rather long,
  and I was tired of seeing half logged out X-Terminals in our
  computer room.  kill(0, SIGHUP) was a much easier fix.  Hey,
  how about a simple "exec fvwm2 -cleanup ..." usage?  That would
  make it obvious within the script where fvwm2 is invoked, and
  where it matters, what behavior required.  Default behavior
  unchanged.  Seem like a good idea?

Be seeing you,

- Sidik

P.S.: We also use fvwm on some very tight, embedded systems where
  having the xinitrc be able to turn into the window manager with
  an exec is both clean and wise to conserve memory/resources.
--
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]