radiusd deadlock on recvfrom on port 1814

[Alan DeKok]

Ryan Melendez wrote:
> I'm not positive that select is lying about data being available. It
> could be that there is data when select is called, but _something_ out
> of line grabs it before recvfrom() can get to it.

  Like what?  There is nothing else listening on that IP address/port.
The socket API makes sure of that.

>  The only time I've
> ran into this in the past(not freeradius) is when some flavor of read is
> called on the socket outside the select loop (bad programming).  I can't
> see anywhere this is happening in freeradius.

  There is only one place in the server where sockets are read: the main
read loop.

> Again, this only started happening when I began running two radiusd
> processes on different interfaces on a multihomed system.  I also have
> radrelay binding to one interface and replicating acct packets to the
> other process.

  Hmm... even 1.1.x can have one process listen on multiple interfaces.
 Why not try that?

  But 2.0 will make this much easier, as you can have different virtual
servers (and thus completely different policies) for each socket.  This
is hard in 1.x.

> I suspect you are correct that some race condition in the kernel
> possibly regarding pthread.  I'm going to continue investigating, I'll
> make the socket non-blocking as a last resort.
> 
> If anyone has experienced this problem before, or has any suggestions
> please let me know.

  I've never seen it.

  Alan DeKok.