Very Computer

(AIX 3.2 IBM Risc-System 6000/530)

Is there a fix for the problem whereby a vi session will continue after it's
parent process (usually a telnet session) is abnormally terminated.  In our
vast multi-user environment this problem is driving me crazy.  One person
will close his xterm window on our machine without exiting vi.  The vi
process continues.  The next person who opens a telnet session to our
machine inherits the old vi process except that he can't send any input to
it because the csh process which also has the /dev/pty intercepts too much
of the input.  Users have to come to me (the system administrator) to search
for the offending vi process, and kill it.

I called IBM on this -- they didn't have anything to fix this problem for
AIX 3.2.  Has anyone else heard differently?  Is there a way to scan the
process tables for vi sessions that no longer have parent /dev/pty's and
kill them (as in a cron task)?

Any help or comments on this frustrating AIX bug would be appreciated.

Thanks.

  Ntl Center for Atmospheric Research, Boulder, CO 80307-1000

[csh bug]

Quote:>I called IBM on this -- they didn't have anything to fix this problem for
>AIX 3.2.  Has anyone else heard differently?  Is there a way to scan the
>process tables for vi sessions that no longer have parent /dev/pty's and
>kill them (as in a cron task)?

ksh weenie at heart ;)

And, of course, the C shell doesn't have that code (and neither would
tcsh).  During the tutorial when the setsid() system call was first
alluded to, you should have heard the cheer that was raised by every
one of the 400 or so students in attendance!!

Being told not to use csh is not acceptable. Even if ksh, sh, or fsh (future
shell) are "better", those that design operating systems should not include
csh if they won't allow it to function in a useful manner.  In other words,
the poor user who has learned csh should not have csh crippled on him just
for the sake of following some standard in signal processing he/she doesn't
care about.  We have many such users.  That kind of philosophy is treating
the standards as more important than the people who use them.  Something
needs to be provided by IBM to address this issue, even if it means bypassing
the standards (as an installable option perhaps).  Other vendors are
capable of providing csh shells (should I mention SUNOS in this newsgroup :-) )
that do not have this silly problem of a user inheriting some other user's
orphaned process and then having to come to me for help.

Now, off the soapbox...  I'm still interested in any solution(s) that
csh users have found to this problem.  Any creative ideas would also
be appreciated, even if you haven't personally tried them out.  Would
"alias vi 'ksh vi'" or something like that work?  We would also have to do
that with elm, tex, emacs, and a few other user utilities.

           Ntl Center for Atmospheric Research, Boulder, CO 80307-3000

I'm used to this happening with man commands on 3.1 (not only do they go on
living, they burn cpu, which is how I usually notice them).

I do ps -ef and look to see what the parent process of a vi or man command is.
If it's 1, it's an orphan, and I nuke it. I'd be more careful with commands
that might more legitimately be running in the background, but I figure these
were meant to be run by a logged-in user only.

*) *) *) *) *) *) *) *) *) *) *)!(* (* (* (* (* (* (* (* (* (* (* (* (*
Jo Ann Malina, Stanford Linear Accelerator Center

Neither Stanford nor the DOE would be caught dead with these opinions.
Nor do they consult me when formulating theirs.