radiusd deadlock on recvfrom on port 1814
rmelendez at wayport.net
Tue Oct 30 21:20:32 CET 2007
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).
"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
More information about the Freeradius-Users