[Infrastructures] ISconf: Cache.py - bcast method

[Steve Traugott]

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