Zsh Mailing List Archive
Messages sorted by:
Re: recovering zombie process
- X-seq: zsh-users 11125
- From: "Brian K. White" <brian@xxxxxxxxx>
- To: <zsh-users@xxxxxxxxxx>
- Subject: Re: recovering zombie process
- Date: Wed, 17 Jan 2007 02:14:22 -0500
- Mailing-list: contact zsh-users-help@xxxxxxxxxx; run by ezmlm
- Organization: Aljex Software
- References: <20070116231141.GC21799@sen> <00d801c739d5$7ce4b890$0901a8c0@venti> <20070117035048.GB10583@xxxxxxxxxxxxxxxxxxx>
----- Original Message -----
From: "Vincent Lefevre" <vincent@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
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
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
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: