Bjørn Mork wrote:
Yes, now it continues to answer both authentication and accounting requests, but it still stops proxying after a while (where "a while" might be something like 20+ hours and 1+ million auth requests - I have no indication that these values are fixed).
Look for the message: Failed creating new proxy socket: server is too busy and home servers appear to be down It *should* continue to proxy after that, but it *won't* create new outgoing sockets. And it *won't* proxy any more requests until the current requests have timed out. If the upstream servers really are that bad, I suggest configuring local detail files, as in raddb/sites-available/robust-proxy-accounting. This should make the server log packets locally, and *not* track them in memory (which appears to be the problem).
There are a number of servers marked "alive", but these are all servers which have been revived after the fixed period. When used, they will be marked dead/zombie again.
Configure "status_check". Really. Get the upstream servers to permit status-checks for a "test" user. It will make your network *much* more robust. And why are the upstream servers dying so consistently? You're really in a corner case where you're testing FreeRADIUS in situations where the network Just Doesn't Work. The suggestions above should help work around most of those issues.
But I will test that now, starting with the stable branch from git.freeradius.org, commit d7b4f003477644978f3fefa694305dce9b5dc8bf, which was the last point where things seemed to work
If that works, we could do a "git bisect" to find the issue. There are only 26 commits since them, and many of those don't have code changes. It shouldn't be too hard to track down the offending commit. Alan DeKok.