Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: uflorida!aaa.com!mikel@gatech.edu ( Mikel Manitius @ American Automobile Association )
Newsgroups: comp.sys.sun
Subject: KSH runaway on SPARC 2 when window CLOSEed
Keywords: Miscellaneous
Message-ID: <2453@brchh104.bnr.ca>
Date: 17 Apr 91 01:00:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 77
Approved: Sun-Spots@rice.edu
X-Original-Date: 9 Apr 91 02:16:22 GMT
X-Sun-Spots-Digest: Volume 10, Issue 81, message 10
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

Enviornment: SunOS 4.1.1 on a SPARC 2, also on SPARC 1 and 470 Server.
	     OpenWindows 2.0 and/or Sunview

I have identified two problems with KSH on the above enviornment:

1. When executing a shell script (including a ".kshrc" via $ENV) KSH will
   become a runaway when the first non-internal command is executed of the
   "monitor" option is set on.

   Note: This problem also seems to occur on 3B2/1000 computers running
   SVR3.2.2 and above.

2. When the window that a KSH is running in is closed by the window
   manager, KSH becomes a runaway if the "vi" and "viraw" options are set on.
   ("ignoreeof" doesn't matter).

The "runaway" ksh simply chews on CPU, but does not core dump, create
large files or do other nasty things. This particular KSH seems to ignore
SIGTERM and SIGHUP when this condition occurs, however a SIGKILL does the
job.

Implemented fix:

I have implemented the following fixes for the above two problems, however
they manipulate the symptoms rather than fixing the problem.  I would like
to hear from anyone that has corrected the problem.

1. In my ".kshrc" file (pointed to by $ENV) I unset "monitor" and allow
   processing as usual. Then at the end, I check to see if "interactive" is
   on. If so, I enable "monitor". If not, this must be a K Shell which is
   going to execute a shell script, so I leave "monitor" off.

   This seems to work quite well. All K Shells source the file pointed to by
   the "ENV" enviornment variable during startup.

2. In my ".kshrc" again, I trap signal 0 (termination of shell) to a
   pre-defined function. The predefined function unsets the trap for 0,
   unsets the "vi" option, and exits. The shell exits cleanly.

   Note that "viraw" doesn't need to be unset, only "viraw", but in my
   instance having "vi" set alone didn't produce the problem.

   Also note that this is not nessecary in the ".profile" because it does an
   "exec" of the window manager for me, and thus does not get closed by one.
   I do suppose however that setting "monitor" prematrely in one's ".profile"
   could cause problem #1.

Here's the code I've used to resolve this:

---cut---
#
# Top of .kshrc
#
set +o monitor
#
[ ... body of ".kshrc" ... ]
#
# Bottom of .kshrc
#
function __cleanup__
{
	trap 0
	set +o vi
	exit
}
#
if set -o | fgrep 'interactive      on' > /dev/null
then
	set -o monitor
	trap "__cleanup__" 0
fi
---cut---

Please submit any comments and suggestions to "mikel@aaa.com".
I will then post a summary followup.
						Mikel Manitius
						mikel@aaa.com