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