On Thu, Jun 18, 2009 at 12:20:40PM -0400, Jim Paris wrote:
> Daniel P. Berrange wrote:
> > We close the socket to the 'nc' process here so in theory it should
> > be getting a HUP event from poll or EOF from read, etc and then
> > exiting. Ominously though I see several patches to Fedora's 'nc'
> >
Daniel P. Berrange wrote:
> On Thu, Jun 18, 2009 at 12:20:40PM -0400, Jim Paris wrote:
> > I'm using Debian. I've already had to switch from the
> > "netcat-traditional" package to the "netcat-openbsd" package.
> > Debian does already include that patch, but what a mess...
>
> I know the reason w
On Thu, Jun 18, 2009 at 12:20:40PM -0400, Jim Paris wrote:
> Daniel P. Berrange wrote:
> > We close the socket to the 'nc' process here so in theory it should
> > be getting a HUP event from poll or EOF from read, etc and then
> > exiting. Ominously though I see several patches to Fedora's 'nc'
> >
Daniel P. Berrange wrote:
> We close the socket to the 'nc' process here so in theory it should
> be getting a HUP event from poll or EOF from read, etc and then
> exiting. Ominously though I see several patches to Fedora's 'nc'
> RPM at least one of which is related to nc hanging forever after
>
On Wed, Jun 17, 2009 at 07:27:22PM -0400, Jim Paris wrote:
> I wrote:
> > > Ok, this bit definitely sounds like a server side bug, unless
> > > perhaps there is some buffering taking place in ssh or nc
> > > causing the errore reply packet to not be send back promptly
> >
> > I'll try to get some
On Wed, Jun 17, 2009 at 06:36:16PM -0400, Jim Paris wrote:
> Daniel P. Berrange wrote:
> > On Wed, Jun 17, 2009 at 05:51:27PM -0400, Jim Paris wrote:
> > > Daniel P. Berrange wrote:
> > > 17:34:59.360: debug : call:6947 : Doing call 70 (nil)
> > > 17:34:59.360: debug : call:7017 : We have the buck
I wrote:
> > Ok, this bit definitely sounds like a server side bug, unless
> > perhaps there is some buffering taking place in ssh or nc
> > causing the errore reply packet to not be send back promptly
>
> I'll try to get some better traces of what's going on here.
The error is getting back to th
Daniel P. Berrange wrote:
> On Wed, Jun 17, 2009 at 05:51:27PM -0400, Jim Paris wrote:
> > Daniel P. Berrange wrote:
> > 17:34:59.360: debug : call:6947 : Doing call 70 (nil)
> > 17:34:59.360: debug : call:7017 : We have the buck 70 0xbccef0 0xbccef0
> > 17:34:59.433: debug : processCallRecvLen:660
On Wed, Jun 17, 2009 at 05:51:27PM -0400, Jim Paris wrote:
> Daniel P. Berrange wrote:
> 17:34:59.360: debug : call:6947 : Doing call 70 (nil)
> 17:34:59.360: debug : call:7017 : We have the buck 70 0xbccef0 0xbccef0
> 17:34:59.433: debug : processCallRecvLen:6605 : Got length, now need 128
> tota
Daniel P. Berrange wrote:
> > But when accessing remotely, I get no useful error, and a hang:
> >
> > $ virsh -c qemu+ssh://j...@server/system
> > libvir: Remote error : authentication failed
> >
> >
> > $ virsh --readonly -c qemu+ssh://j...@server/system
> > libvir: Remote error : authenticatio
On Thu, Jun 11, 2009 at 05:47:29PM -0400, Jim Paris wrote:
> Hi,
>
> I have libvirt 0.6.4 running kvm instances on a headless server.
> I'm using virt-manager 0.7.0 to manage them. In the past, I would SSH
> in and run virt-manager as root. Since running GTK apps as root is no
> good, I've switc
Hi,
I have libvirt 0.6.4 running kvm instances on a headless server.
I'm using virt-manager 0.7.0 to manage them. In the past, I would SSH
in and run virt-manager as root. Since running GTK apps as root is no
good, I've switched to policykit authentication. By default, the
libvirt policy only
12 matches
Mail list logo
