Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: recovering zombie process

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

Messages sorted by: Reverse Date, Date, Thread, Author