On Tue, Apr 24, 2007 at 01:12:26PM +0200, Alan DeKok wrote:
> Kostas Zorbadelos wrote:
> > I disagree with you on this one Alan. I discovered all these issues I
> > mention the hard way, after our radius server stopped running in
> > random times (after a failure in rad_assert() in request_list.c around
> > the section
> > In production environments the server should be able to at least
> > report the errors it encounters and continue operations. Service
> > availability is the most important.
> My point was that it should continue doing *what*? The assertions are
> there to catch catastrophic failures in the code. If the assertion
> trips, it's doing so because the error is non-recoverable.
> If you disable the assertions, the server may look like it's still
> running. But there's no guarantee that it will do anything useful. It
> may crash randomly later, for reasons that are difficult to track down.
> The only *safe* thing to do is to revert to a known working state.
> i.e. restart from scratch.
In the code snippet I sent, from what I can tell, nothing catastrophic
happens. The code checks to see if it is time to send a delayed reject
back to the client and asserts that there is no child thread that
works on that request. Anyway, if the developer flags are switched off
rad_assert() does nothing. This is the way it is defined:
#define rad_assert(expr) ((void) (0))
#define rad_assert(expr) \
((void) ((expr) ? 0 : \
rad_assert_fail (__FILE__, __LINE__)))
So if someone compiles freeradius without developer flags he actually
de-activates all assertions :)
> > As far as I can tell, the following minor patch should take care of the
> > issue of having developer flags switched off be default:
> OK, thanks.
There is the Solaris issue however. I will try to track it down and
send a patch for this too if I can.
> Alan DeKok.
> http://deployingradius.com - The web site of the book
> http://deployingradius.com/blog/ - The blog
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html