On Mon, Feb 15, 2010 at 12:00:50PM -0500, Cole Robinson wrote:
> 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.
Ok, what's going on is this
1. Login & manually run nc
# ssh somehost
$ nc -U /var/run/libvirt/libvirt-sock-ro
In this case the shell gets a controlling TTY. When the SSH client quits, the
kernel's TTY notices EOF, and everything running under the TTY get SIGHUP
2. Remote command executuon
ssh somehost "nc -U /var/run/libvirt/libvirt-sock-ro"
There is no controlling TTY. When the SSH client quits, nc sees the
EOF, but decides to carry on running. No SIGHUP is around, since there's
no TTY to trigger one.
There's no obvious way to ensure that remote SSH command execution sees
SIGHUP like a SSH shell session would.
The situation we're in with 'nc' is rather a trainwreck, and I'm inclined
to say that it is time we took it out of the equation completely, by adding
our own command /usr/libexec/libvirt-ssh-helper
We can execute
ssh somehost "test -e /usr/libexec/libvirt-ssh-helper &&
/usr/libexec/libvirt-ssh-helper /var/run/libvirt/libvirt-sock-ro ||
nc -U /var/run/libvirt/libvirt-sock-ro"
The latter bit just being backwards compatibility code for old libvirt server
deployments lacking the ssh-helper.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list