On 02/15/2010 09:47 AM, Daniel P. Berrange wrote:
On Mon, Feb 15, 2010 at 09:39:31AM -0500, Cole Robinson wrote:
On 02/15/2010 06:11 AM, Daniel P. Berrange wrote:
On Fri, Feb 12, 2010 at 10:32:17AM -0500, Cole Robinson wrote:
This ugly thing is a shell script to detect availability of the -q option for 'nc': debian and suse based distros need this flag to ensure the remote nc will exit on EOF, so it will go away when we close the tunnel. If it doesn't go away, a useless 'nc' process is left sitting on the remote host.
Fedora's 'nc' doesn't have this option, so we can't blindly pass -q. More info here:
I don't really like this approach. Shouldn't it be sufficient to just explicit SIGKILL the ssh client, rather than relying on the exit-on-EOF behaviour of nc.
kill() helps prevent virt-manager from hanging, but it doesn't address the dangling 'nc' process on the remote host that requires -q. Every connection will leave an 'nc' process hanging.
It does when I try it. Killing the SSH client connection results in SIGHUP for the process running on the remote host & nc exits on SIGHUP.
Connecting to a debian system? I just tried using the attached patch on top of latest git (not my patches): Running virsh --connect URI to a debian lenny system, then invoking 'quit', leaves 'nc -U' processes running. 'quit' doesn't hang like it does with current git, but the nc process isn't closed on the remote host. Any recommendations? Thanks, Cole