"Allister Maguire" <[EMAIL PROTECTED]> wrote:
>> Sat Aug 10 19:00:16 2002 : Error: WARNING: Unresponsive child (id
>> 5126) for request 21379
> This is a problem, and may be a mjor cause behind the crash.
> Something is so screwed up that the requests cannot be completed in a
> reasonable amou
"Allister Maguire" <[EMAIL PROTECTED]> wrote:
> Sat Aug 10 19:00:16 2002 : Error: WARNING: Unresponsive child (id 5126)
> for request 21379
This is a problem, and may be a mjor cause behind the crash.
Something is so screwed up that the requests cannot be completed in a
reasonable amount of tim
Hello,
I am have a problem with freeRadius crashing, it happens about once
every 1 to 2 days, I have allow_core_dumps = yes but there is no core
dump, below is the radius log before it crashed.
Sat Aug 10 18:58:54 2002 : Auth: Login OK: [[EMAIL PROTECTED]] (from
client ipnet port 126)
Sat Aug
"Todd T. Fries" <[EMAIL PROTECTED]> wrote:
> While non-optimal, would a mutex lock around non threadsafe functions be a
> viable workaround? It at least allowed a program I've written to function
> safely ..
That's about as much work as fixing the code to use the thread-safe
functions, instead
While non-optimal, would a mutex lock around non threadsafe functions be a
viable workaround? It at least allowed a program I've written to function
safely ..
Penned by Alan DeKok on Mon, Feb 25, 2002 at 05:44:48PM -0500, we have:
| [EMAIL PROTECTED] (Rainer Clasen) wrote:
| > Even with the chan
[EMAIL PROTECTED] (Rainer Clasen) wrote:
> Even with the changes from the radiusd.c you sent me, this goto is still
> triggered.
I think it's the threading problems. The server still uses
a few functions which aren't thread-safe, and they should be made
thread safe.
e.g. gmtime(),. etc.
Hallo erstmal!
Rainer Clasen schrieb:
> Rainer Clasen schrieb:
> > Alan DeKok wrote:
> > > Hmm... I would suggest going to src/main/radiusd.c, function
> > > refresh_request(). Look for:
> > [...]
> > >and add:
> > >
> > > if (request->reply && (request->reply->code != 0)) goto setup_ti
Hallo erstmal!
Rainer Clasen schrieb:
> Alan DeKok wrote:
> > Hmm... I would suggest going to src/main/radiusd.c, function
> > refresh_request(). Look for:
> [...]
> >and add:
> >
> > if (request->reply && (request->reply->code != 0)) goto setup_timeout;
>
> I've added this to the ve
[EMAIL PROTECTED] (Rainer Clasen) wrote:
> I've taken the changes from CVS and applied them to my patched version
> (only logging enhancements). proxy.c:1.52-1.53, radiusd.c:1.238-1.239.
>
> I got the following backtrace:
>
...
> (gdb) p *request
> $1 = {magic = 16909060, packet = 0x0, proxy = 0
Alan DeKok wrote:
> Hmm... I would suggest going to src/main/radiusd.c, function
> refresh_request(). Look for:
[...]
>and add:
>
> if (request->reply && (request->reply->code != 0)) goto setup_timeout;
I've added this to the version already running with your fix from
yesturday.
No
Alan DeKok wrote:
> [EMAIL PROTECTED] (Rainer Clasen) wrote:
> > in both cases the only server for a realm was marked dead immediately
> > before the crash.
>
> On further examination, the code in rad_respond() does NOT check for
> errors returned from proxy_send(). So if the request is marke
[EMAIL PROTECTED] (Rainer Clasen) wrote:
> in both cases the only server for a realm was marked dead immediately
> before the crash.
On further examination, the code in rad_respond() does NOT check for
errors returned from proxy_send(). So if the request is marked to be
proxied, and the realm
[EMAIL PROTECTED] (Rainer Clasen) wrote:
> I've taken a look at the logs and there is a pattern:
>
> in both cases the only server for a realm was marked dead immediately
> before the crash.
OK, that helps a *lot*.
> In both cases the Server seems to be marked dead eronously:
>
> Tue Feb 1
Rainer Clasen wrote:
> in both cases the only server for a realm was marked dead immediately
> before the crash.
I forgot to mention: This server has the secret, which is in
request->proxy_secret when the daemon dies. So it seems to be a packet
related to the same server which was marked dead.
Alan DeKok wrote:
> [EMAIL PROTECTED] (Rainer Clasen) wrote:
> > Mitchell, Michael wrote:
> > > I'm currently testing freeradius-snapshot-20020114 (configured as a proxy
> > > only) on Solaris 8 and running into a problem.
> >
> > I'm seeing similar crashes with my patched 2002-02-11 version on S
Mitchell, Michael wrote:
> I'm currently testing freeradius-snapshot-20020114 (configured as a proxy
> only) on Solaris 8 and running into a problem.
I'm seeing similar crashes with my patched 2002-02-11 version on Solaris
7.
#0 0x19510 in proxy_send (request=0x1b13250) at proxy.c:398
3
[EMAIL PROTECTED] (Rainer Clasen) wrote:
> Mitchell, Michael wrote:
> > I'm currently testing freeradius-snapshot-20020114 (configured as a proxy
> > only) on Solaris 8 and running into a problem.
>
> I'm seeing similar crashes with my patched 2002-02-11 version on Solaris
> 7.
Hmm... I'm star
"Mitchell, Michael" <[EMAIL PROTECTED]> wrote:
> 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 the
---
> 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
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 tr
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 c
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 w
22 matches
Mail list logo
