radiusd deadlock on recvfrom on port 1814

[Ryan Melendez]

On Thu, 2007-10-18 at 01:10 +0200, Alan DeKok wrote:
> Ryan Melendez wrote:
> > I've had FreeRADIUS Version 1.1.0 hang twice recently.  The core dumps
> > are very similar in that it appears that main is waiting on some stuff
> > from port 1814.  Honestly I don't know what 1814 is really for (proxy
> > port?) but it seems as if fd_isset says so we should expect some data on
> > that socket.  Unless something _else_ had already received that data.
> 
>   1814 is for proxying, yes.  And it shouldn't hang... it should do
> *something* at least.
> 
> > I hadn't noticed this before I added radrelay and another radiusd
> > process on the same box.  Both radiusd processes are bound to different
> > virtual interfaces and radrelay is duplicating acct packets from one to
> > the other.  It's not obvious why there would be a race condition on that
> > socket, but my guess is something is going on there.  It seems as though
> > both radiusd processes are using the same descriptors for each of their
> > three sockets.  I've included some debug info from the core files.
> 
>   The descriptors are local to the process, and don't mean anything.
> 
> > Is this a know bug or can it be fixed with a configuration change?
> 
>   It sounds like a kernel bug to me.  recvfrom() on a UDP socket
> *always* returns quickly.  If there's no data, it returns immediately
> with an error.  If there is data it returns the data.
> 
>   If recvfrom() hangs, then it's not the fault of the application.  And
> there's nothing the application can do to fix it.
recvfrom() blocks on datagram sockets just like any other type of socket
unless it gets a S0_RCVTIMEO or the O_NONBLOCK is set (in which case you
would receive an error). 

http://www.opengroup.org/onlinepubs/000095399/functions/recvfrom.html

"If no messages are available at the socket and O_NONBLOCK is not set on
the socket's file descriptor, recvfrom() shall block until a message
arrives. If no messages are available at the socket and O_NONBLOCK is
set on the socket's file descriptor, recvfrom() shall fail and set errno
to [EAGAIN] or [EWOULDBLOCK]."

> 
>   Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html