Is there a fix for problem w vi sessions not dying when parent dies?

Is there a fix for problem w vi sessions not dying when parent dies?

Post by Timothy Fredri » Sun, 14 Jun 1992 06:10:07



(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

 
 
 

Is there a fix for problem w vi sessions not dying when parent dies?

Post by Glenn R. Sto » Thu, 18 Jun 1992 03:22:10



[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)?

If somebody comes up with such a scanner, make sure and make the task to be
slain a variable, or a *.cfg list of some sort, because emacs does the same
thing... and please post it. :)   As far as I can tell, the problem here is
intrinsic to csh-ishness, because tcsh (which we brought in 3rd party) does
the same thing... I think it has something to do with the fact that csh
doesn't SIGHUP its children when it exits, unlike ksh and sh, which do.
<sigh>


ksh weenie at heart ;)

 
 
 

Is there a fix for problem w vi sessions not dying when parent dies?

Post by Cras » Thu, 18 Jun 1992 11:45:00




>[csh bug]
>>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)?

>If somebody comes up with such a scanner, make sure and make the task to be
>slain a variable, or a *.cfg list of some sort, because emacs does the same
>thing... and please post it. :)   As far as I can tell, the problem here is
>intrinsic to csh-ishness, because tcsh (which we brought in 3rd party) does
>the same thing... I think it has something to do with the fact that csh
>doesn't SIGHUP its children when it exits, unlike ksh and sh, which do.
><sigh>

That would concur with the data presented at the January Usenix in the
System V Release 4 Internals tutorial.  In that tutorial was a
discussion of the "session id" concept as introduced by POSIX.
Apparently the old BSD mechanism could leave orphaned process groups
attached to a terminal when a user logs out.  POSIX added the setsid()
call to allow a shell to because a group leader for a terminal.  A
process which does setpgrp() becomes a background process group.  If
the parent now dies, ie the child is an "orphaned" process group, the
OS only has the connection between the parent and the terminal, not
the child and the terminal.

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!!


>ksh weenie at heart ;)

Basically, don't use the C shell.  I'm very opinionated on this
particular point...  No use arguing it with me, so flames are directed
to /dev/null.
--
Frank "Crash" Edwards            King Marine Electronics, Inc.
Home: 813/786-3675               Work: 813/530-3411
    "Timba; his arms open."
 
 
 

Is there a fix for problem w vi sessions not dying when parent dies?

Post by Timothy Fredri » Fri, 19 Jun 1992 08:54:43





>>[csh bug]
>>>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)?

>>If somebody comes up with such a scanner, make sure and make the task to be
>>slain a variable, or a *.cfg list of some sort, because emacs does the same
>>thing... and please post it. :)   As far as I can tell, the problem here is
>>intrinsic to csh-ishness, because tcsh (which we brought in 3rd party) does
>>the same thing... I think it has something to do with the fact that csh
>>doesn't SIGHUP its children when it exits, unlike ksh and sh, which do.
>><sigh>

>That would concur with the data presented at the January Usenix in the
>System V Release 4 Internals tutorial.  In that tutorial was a
>discussion of the "session id" concept as introduced by POSIX.
>Apparently the old BSD mechanism could leave orphaned process groups
>attached to a terminal when a user logs out.  POSIX added the setsid()
>call to allow a shell to because a group leader for a terminal.  A
>process which does setpgrp() becomes a background process group.  If
>the parent now dies, ie the child is an "orphaned" process group, the
>OS only has the connection between the parent and the terminal, not
>the child and the terminal.

>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!!


>>ksh weenie at heart ;)

>Basically, don't use the C shell.  I'm very opinionated on this
>particular point...  No use arguing it with me, so flames are directed
>to /dev/null.
>--
>Frank "Crash" Edwards            King Marine Electronics, Inc.
>Home: 813/786-3675               Work: 813/530-3411
>    "Timba; his arms open."

Okay, I'm going to step on the soapbox for a moment:

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

 
 
 

Is there a fix for problem w vi sessions not dying when parent dies?

Post by Jo Ann Mali » Fri, 19 Jun 1992 12:04:06



|>
|> (AIX 3.2 IBM Risc-System 6000/530)
|>
|> 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)?
|>

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.