Hi Randy, Thanks for your help.
Setting "cleanup_delay" to "0" seems to have helped to alleviate the problem, but it does not prevent it. The server tends to run longer before crashing - we're into the minutes now rather than seconds - but the problem is definitely still there. I saw an email in the archives from Alan that from memory said the server should not be considered "stable" running non-threaded. Is this still the case, or has this code been cleaned up now? It was a reasonably old email I think. Thanks, Michael > -----Original Message----- > From: Randy Moore [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, 16 January 2002 11:15 > To: [EMAIL PROTECTED] > Subject: Re: FreeRADIUS crashing on Solaris 8 > > > Hi, > > In radiusd.conf, try setting 'cleanup_delay' to 0 or even > -1. It seems to > be related to some different segfaults I've been seeing. > Mine have to do > with CHAP requests and SQL authentication. > > At 07:47 AM 1/16/2002 +0800, you wrote: > >Hi, > > > >I have the exact same problem (almost same gdb trace running on Linux > >too. > > > >It seems that the proxy.c is giving problem. I setup two clients > >(using radclient) to send the acct records to the radius > daemon which > >then proxied to another server. With 1 client everything is > fine. Once > >the next client kicks in, the daemon crashed. > > > >/hh > > > >On Wed, 16 Jan 2002, Mitchell, Michael wrote: > > > > > Hello list, > > > > > > I'm currently testing freeradius-snapshot-20020114 > (configured as a proxy > > > only) on Solaris 8 and running into a problem. > > > > > > radiusd will run for a short (seemingly random) period of > time (any where > > > from say 10 seconds to 30 seconds) and happily processing > requests until it > > > simply dies with a signal 9 (SIGKILL??) and core dumps. > The problem also > > > seems to relate to the load put on the server. At 4 or 5 > requests per > > second > > > it will start to exhibit the crashing behaviour within > about 30 seconds. At > > > 2 or 3 requests per second it is taking several minutes > for the problem to > > > appear. > > > > > > The problem also has only so far appeared for accounting requests. > > > > > > Maybe there is a timing issue somewhere, since accounting > requests take > > that > > > much longer to process as my proxy has to wait for a > response to come back > > > from the second radius server? > > > > > > Using gdb it appears that radiusd is crashing at at least > a few different > > > places, which is not very helpful, and kind of suggests > it may not be an > > > actual bug in FreeRADIUS? > > > > > > Here are three back traces that I captured: > > > > > > #0 0x188b4 in proxy_send (request=0x9cb18) at proxy.c:317 > > > 317 request->proxy->timestamp = > request->timestamp; > > > (gdb) bt > > > #0 0x188b4 in proxy_send (request=0x9cb18) at proxy.c:317 > > > #1 0x15480 in rad_respond (request=0x9cb18, fun=0x170a0 > <rad_accounting>) > > > at radiusd.c:1527 > > > #2 0x1ecf8 in request_handler_thread (arg=0x98110) at > threads.c:169 > > > > > > > > > -------------------------------------------------------------- > -------------- > > > - > > > > > > #0 0xff141da4 in t_delete () from /usr/lib/libc.so.1 > > > (gdb) bt > > > #0 0xff141da4 in t_delete () from /usr/lib/libc.so.1 > > > #1 0xff141998 in realfree () from /usr/lib/libc.so.1 > > > #2 0xff14226c in cleanfree () from /usr/lib/libc.so.1 > > > #3 0xff1413a0 in _malloc_unlocked () from /usr/lib/libc.so.1 > > > #4 0xff141294 in malloc () from /usr/lib/libc.so.1 > > > #5 0x22538 in rad_decode (packet=0xa00f8, original=0xa3b68, > > > secret=0x98dec "gloople") at radius.c:1060 > > > #6 0x15208 in rad_respond (request=0x98da0, fun=0x170a0 > <rad_accounting>) > > > at radiusd.c:1437 > > > #7 0x1ecf8 in request_handler_thread (arg=0x982f0) at > threads.c:169 > > > > > > > > > -------------------------------------------------------------- > -------------- > > > - > > > > > > #0 0x23220 in pairfind (first=0x190, attr=41) at valuepair.c:97 > > > 97 first = first->next; > > > (gdb) bt > > > #0 0x23220 in pairfind (first=0x190, attr=41) at valuepair.c:97 > > > #1 0x1888c in proxy_send (request=0x9d728) at proxy.c:312 > > > #2 0x15480 in rad_respond (request=0x9d728, fun=0x170a0 > <rad_accounting>) > > > at radiusd.c:1527 > > > #3 0x1ecf8 in request_handler_thread (arg=0xa70f0) at > threads.c:169 > > > > > > This appears to point back to the threading, but whether > it is a Solaris > > > issue or a FreeRADIUS issue I'm not really sure. > > > > > > The log files don't appear (to me) to give a definitive > answer to what is > > > happening here, except that at the time of the "crash", > I'm getting > > > incomplete attribute logging such as: > > > > > > Thread 2 handling request 167, (17 handled so far) > > > Proxy-State = 0x313639 > > > Sending Accounting-Response of id 169 to 203.108.109.27:62729 > > > Finished request 167 > > > Going to the next request > > > Thread 2 waiting to be assigned a request > > > NAS-IP-Address = 203.108.109.27 > > > = 1 > > > = Async > > > = Start > > > = "123" > > > Proxy-State = "169" > > > = UNKNOWN-TYPE > > > > > > When I run the server with the "-s" option it seems to > fun fine and > > does not > > > exhibit this behaviour. > > > > > > Once again this appears to point towards a problem with threading? > > > > > > I know there are at least a couple of people running > FreeRADIUS on > > Solaris 8 > > > and just wondering if anyone can possibly point me in a > direction to start > > > looking for the problem, or if there is a known issue > with solaris that > > > requires a patch or something similar? > > > > > > > > > Many thanks for your time and effort, > > > Michael > > > > > > - > > > List info/subscribe/unsubscribe? See > > http://www.freeradius.org/list/users.html > > > > > > > > > >- > >List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Randy Moore Axion Information Technologies, Inc. email [EMAIL PROTECTED] phone 301-408-1200 fax 301-445-3947 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
