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. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
