Well, now it fails before even doing the first request, and no core :(
Listening on IP address *, ports 1645/udp and 1646/udp.
Ready to process requests.
rad_recv: Access-Request packet from host 207.136.103.131:2981, id=4,
length=44
User-Name = "test"
Password =
"\361h\356\036\231\263^\035\016\250\244\271\365?q\007"
modcall: entering group authorize
MASTER: exit on signal (11)
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]] On Behalf Of
> [EMAIL PROTECTED]
> Sent: October 25, 2001 5:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Problems starting radiusd
>
>
> "Jason Lixfeld" <[EMAIL PROTECTED]> wrote:
> > **Request finished. Now, same thread waiting for next request:
> >
> > Going to the next request
> > Thread 1 waiting to be assigned a request
> >
> > **Check `top`, radiusd process is @99% CPU.
>
> OK, grab the latest cvs version, and do a
> './configure;make;make install'. I've found problems with
> signal handling in the threads.
>
> If that doesn't solve the problem, go to src/main/threads.c, and
> add:
>
> sigaddset(&set, SIGSEGV);
>
>
> with the other 'sigaddset' lines.
>
> > > - it happens in threaded mode and when running '-s'
> >
> > No, in -s it's fine:
>
> That's pretty telling.
>
>
> The issue appears to be that the sem_wait() call in the
> threads code gives a SEGV when signals are received. Very weird.
>
>
> I think that this change will at least cause the server to
> NOT use all of the CPU. It may still core dump, but that's a
> Good Thing, if the core dump tells us what the problem is.
>
> Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
