Re: recovering zombie process

["Brian K. White" <brian@xxxxxxxxx>]

----- Original Message ----- 
From: "Vincent Lefevre" <vincent@xxxxxxxxxx>
To: <zsh-users@xxxxxxxxxx>
Sent: Tuesday, January 16, 2007 10:50 PM
Subject: Re: recovering zombie process


> On 2007-01-16 20:19:08 -0500, Brian K. White wrote:
> > 2) freeware tty multiplexing/cloning software
> >    ttysnoop
> >    screen / mscreen
>
> Is there a way to use them transparently?

Except for screen that is exactly how they are designed to work.
They each work by different means though, resulting in different levels of 
perfection of transparency.

DoubleVision is the best, it's a kernel module and hooks in somewhere in the 
kernel tty layer.
And it impliments terminfo based terminal translation so a users on 
dissimilar terminals can dv each other and the escape codes and keystrokes 
all get translated so the two terminals stay sensible.
It's impractical to use on linux though because your kernel is always a 
moving target not supported by the module.
It's wonderful on commercial OS's where you have the same kernel as everyone 
else, or at least the interface for kernel modules is documented and very 
rarely changed, and very very very rarely changed in a way that breaks 
backwards compatibility.

ttysnoop works by replacing /bin/login
Thats both good and bad.

The good is:
 safer, all userland, no messing with your kernel.
 safer, can be used on some services, or even individual ttys, while others 
are not touched.
 doesn't require rebootig or disrupting the box to put in or take out.

The bad is:
more of a pain in the neck to get it in place since each service that might 
possibly generate a tty needs to be dealt with seperately. Even if you 
actually replace /bin/login instead of figuring out the individual service 
configurations like adding -L /some/program to telnetd, most services can be 
configured not to use /bin/login, and so you still have to go tell them to 
use it.
Some services simply can't use ttysnoop no matter what. FacetWin (commercial 
terminal emulator that only talks to it's proprietary server daemon) does 
not use any standalone login and does not have any option to do so, and so 
there is no place to inject ttysnoop. But in most cases, if you're using 
FacetWin instead of telnet or openssh, then you are also using 
sco,sun,aix,hpux,etc.. where doublevision is practical.

ttysnoop has other failings though. it's very crude, does no terminal type 
translation, and hasn't been maintained in years.
There are patched versions to support unix98 pty's but so far I don't think 
any are 100% yet. There is a known bug where, on unix98 pty's (2.6 kernels), 
ttysnoop fails to update utmp/wtmp when closing some sessions and so w/who 
etc show users logged in who aren't.

I've never used peek. If I'm gonna pay, DoubleVision is less than half the 
price and works at a lower level, and works awsome, and is proven up the 
wazoo since most of my sco customers over the years have gotten it.
For the price of peek on just one box, (unlimited version, which I'd need 
since my user count on any one of several boxes is over double than peek's 
next highest user count.) I could probably pay a programmer to nail down 
ttysnoop. I don't really have dissimilar terminals that much any more, at 
least not enough that this limitation would be insufferable.

I'm still in the process of really figuring out if ttysnoop can work out ok 
or not though. We definitely need something, be it 
doublevision,ttysnoop,peek,other...
We use it a lot for customer support and training.

It's useful for some sysadmin (both os and db type) tasks too but I think 
screen can be used for those.
We'd use dv to connect to a console tty before doing some critical procedure 
that would be ReallyBad(tm) if it crashed in the middle. If the net 
connection or terminal emulator barfs, just reconnect. The app kept running 
on the console. For that matter, if you can't reconnect you can actually 
drive to the site and access that console directly. We can probably just use 
screen for that.


> > By rights, these processes should have all received a hangup when the
> > parent went away.
>
> If the parent has crashed, there's no hangup.

Then shouldn't the next higher parent do it?
If it were a telnet session that'd be telnetd. In the case of an xterm I'm 
not sure where that responsibility should lie.
X? window manager? the shell that ran startx or xdm? init? the kernel?

Brian K. White  --  brian@xxxxxxxxx  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!