[Infrastructures] RE: ISconf: Cache.py - bcast method

[Jordan Curzon]

My python version is 2.4.1.

I am testing it on an imaged XEN virtual machine. I haven't tested it
on real hardware, or a different distro.

I havn't had the change to test wrap ing it in blocking calls.

On 12/19/05, Steve Traugott <stevegt@terraluna.org> wrote:
> Curiouser and curiouser.  What happens if you set the socket to
> blocking before the sendto() call, then back to nonblocking again
> afterwards?  I.E.:
>
>     self.sock.setblocking(1)
>     self.sock.sendto(msg,0,(addr,self.udpport))
>     self.sock.setblocking(0)
>
> Has this only happened on one machine?  Out of how many?  Does dmesg
> say anything interesting (e.g. link state transients)?
>
> Steve
>
> On Mon, Dec 19, 2005 at 04:49:57PM -0700, Jordan Curzon wrote:
> > Yes, from the sendto call. The machine is just for testing ISCONF. It
> > is a clean install of Ubuntu with simple routing (just gets a dhcp
> > address). I am not using the IS_NETS file and the address that fails
> > is <broadcast>. Also, the call succedes for some number of calls then
> > throws the exception.
> >
> > On 12/19/05, Steve Traugott <stevegt@terraluna.org> wrote:
> > > On Mon, Dec 19, 2005 at 07:49:16AM -0700, Jordan Curzon wrote:
> > > > Keeps crashing on me on the last line of the bcast method
> > > > in Cache.py.  It throws a socket.error exception with the
> > > > EAGAIN error. I did some looking and other places in the
> > > > code ignore that error. I trapped the exception and
> > > > everything runs fine.
> > > >
> > > > Is that a bug or am I misunderstanding things.
> > >
> > > You're getting an EAGAIN from a UDP sendto(), right?
> > > Bizarre.  That means that the operation would block (and I
> > > have the socket set for non-blocking).  Not sure what would
> > > cause that in UDP.  Without knowing what's causing this, I'm
> > > not sure whether the correct action is to trap and discard
> > > the exception, or to yield and retry later.  Some ideas:
> > >
> > > - If you're using a nets file, check to make sure all of the
> > >   IP addresses in there are valid and routable.  Check your
> > >   routing table as well...  Add a debug() call to your patch
> > >   to show the address that's failing.
> > >
> > > - Check to see if there's something seriously wrong with the
> > >   IP stack on the machine -- running out of mbufs maybe?
> > >   What else is the machine doing?
> > >
> > > Anyone else have any ideas for what might cause a UDP
> > > sendto() to block?
> > >
> > > I've created bug #63 to track this: http://trac.t7a.org/isconf/ticket/63
> > >
> > > Steve
> > >
> > > --
> > > Stephen G. Traugott  (KG6HDQ)
> > > UNIX/Linux Infrastructure Architect, TerraLuna LLC
> > > stevegt@TerraLuna.Org
> > > http://www.stevegt.com -- http://Infrastructures.Org
> > >
> > _______________________________________________
> > Infrastructures mailing list
> > Infrastructures@mailman.terraluna.org
> > http://mailman.terraluna.org/mailman/listinfo/infrastructures
>
> --
> Stephen G. Traugott  (KG6HDQ)
> UNIX/Linux Infrastructure Architect, TerraLuna LLC
> stevegt@TerraLuna.Org
> http://www.stevegt.com -- http://Infrastructures.Org
>