Eric Geier wrote:
> The server keeps crashing, sometimes within 10 minutes or sometimes after
> weeks. I'm using the supervise command to start/run it and here's what I get
> after it crashes. Please help. Is there a setting I should tweak or check?
> I'm running 1.1.8 and yes I should upgrade, but
The server keeps crashing, sometimes within 10 minutes or sometimes after
weeks. I'm using the supervise command to start/run it and here's what I get
after it crashes. Please help. Is there a setting I should tweak or check?
I'm running 1.1.8 and yes I should upgrade, but could you please still he
Amr el-Saeed wrote:
> after the server finishes starting the mysql connections, it prints
> that error Error: FATAL: Thread create failed: Cannot allocate memory
> , and starts to connect to mysql again and the error again and so on
It sounds like your system doesn't support threads that well
after the server finishes starting the mysql connections, it prints
that error Error: FATAL: Thread create failed: Cannot allocate memory
, and starts to connect to mysql again and the error again and so on
Amr el-Saeed wrote:
i'm running Linux version 2.4.21-51.EL
([EMAIL PROTECTED]) (gcc
i'm running
Linux version 2.4.21-51.EL ([EMAIL PROTECTED])
(gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-58))
Amr el-Saeed wrote:
Dear Alan,
Thanks for your reply
first, i have about 200,000 users but there is some thin g in the
configuration that makes the users connects and disconn
Amr el-Saeed wrote:
> first, i have about 200,000 users but there is some thin g in the
> configuration that makes the users connects and disconnects in less
> than 15 minutes , and that makes that huge number of requests
> (it's a temp. situation ) of-course.
Well, that should be fixed.
> s
Dear Alan,
Thanks for your reply
first, i have about 200,000 users but there is some thin g in the
configuration that makes the users connects and disconnects in less
than 15 minutes , and that makes that huge number of requests
(it's a temp. situation ) of-course.
second i tried the conf
Amr el-Saeed wrote:
> Sorry
> the config. was in the first email
>
> I have this configuration
.
... thread stuff. There's usually a LOT more configuration than that.
> start_servers = 20
> max_servers = 400
> min_spare_servers = 30
> max_spare_servers = 60
I would suggest setting:
start_s
Sorry
the config. was in the first email
I have this configuration
start_servers = 20
max_servers = 400
min_spare_servers = 30
max_spare_servers = 60
max_requests_per_server = 0
i have 4G memory , this is the Top result
Mem: 4090068k av, 420312k used, 3669756k free, 0k shrd, 15408k
Amr el-Saeed wrote:
> OS: Red Hat Enterprise Linux AS release 3
> FreRadius : freeradius-1.1.0-1
Why not 1.1.7? Let me guess... RedHat doesn't ship it.
> Number of requests : i need about 10,000 request concurrent
I don't know what that means. 10,000 requests per second? Or 10,000
users
Dear Alan,
OS: Red Hat Enterprise Linux AS release 3
FreRadius : freeradius-1.1.0-1
Number of requests : i need about 10,000 request concurrent
the server starts and after 1 or 2 mins it crashes
does any thing of my configuration is wrong ? and how to fine tune my
freeRadius server ??
thanks
Amr el-Saeed wrote:
> the log file each less than a minute logs that the server can't allocate
> memory
>
> Error: FATAL: Thread create failed: Cannot allocate memory
Odds are that the server is trying to start too many threads, and that
there is some OS limitation on the number of threads per
Amr,
Please include some details.
What Operating System
What Version of Free Radius?
How Long has the server been running?
What changed before this started happening?
Thanks
On 10/11/07 9:01 AM, "Amr el-Saeed" <[EMAIL PROTECTED]> wrote:
> Dear All,
>
> I have a big problem with my freeRadius s
Dear All,
I have a big problem with my freeRadius server
the log file each less than a minute logs that the server can't allocate
memory
Error: FATAL: Thread create failed: Cannot allocate memory
I have this configuration
start_servers = 20
max_servers = 400
min_spare_servers = 30
max_spare
inverse wrote:
> EAP-TLS is implemented and works fine, so does the CRL.
> My problem is as follows: the HUP works but radiusd segfaults at the
> first authentication after the HUP.
The server doesn't handle HUP that well. You're *much* better off
just killing it and re-starting it.
> Now I'm
lt. That would imply that radiusd crashes before
it writes the first debug message.
bye
Daniel
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von inverse
Gesendet: Freitag, 20. April 2007 10:36
An: FreeRadius users mailing list
Betreff: Re: server
I have to reload the server
> config, right? Since the update the server crashes with a seg fault about a
> minute after the config reload - but only if the crl changed. For now I
> changed the reload (SIGHUP) to a complete restart as a work around. Before
> we used freeradius 1.1.4.
m
Hello,
this week I updated to freeradius 1.1.6. We use eap/tls with a crl from
a Microsoft CA, which is downloaded and converted by a shell script
every hour or has to be updated manually. If it changes, I have to
reload the server config, right? Since the update the server crashes
with a seg
Am Donnerstag, den 23.12.2004, 14:37 -0500 schrieb Alan DeKok:
> The solution is to re-write some of the code for handling requests
> && timeouts. I've been looking at it recently, and have decided that
> it could use some updates for other issues, and now this, too.
Sounds good! I'll wait the
Stephan Jaeger <[EMAIL PROTECTED]> wrote:
> I'm still experiencing server crashes under some high load situations.
>
> "Error: Assertion failed in threads.c, line 285"
What's probably happening is that the server is CPU starved, and the
request is being
Hi,
I'm still experiencing server crashes under some high load situations.
"Error: Assertion failed in threads.c, line 285"
bt:
Program received signal SIGABRT, Aborted.
[Switching to Thread 1077318912 (LWP 29184)]
0x40254ed9 in raise () from /lib/tls/libc.so.6
(gdb) bt
#0 0x40
Stephan Jaeger <[EMAIL PROTECTED]> wrote:
> Here you go, this time another it happend in another line of request_list.c:
>
> Assertion failed in request_list.c, line 580
Ok. *That* error is expected. I haven't added code to allocate
more sockets when the current one gets full.
Under high l
On Mon, 2004-05-24 at 09:51 -0400, Alan DeKok wrote:
> Stephan Jaeger <[EMAIL PROTECTED]> wrote:
> > Testing the newest freerad version i ran into some problems with the
> > server crashing under very-high-load situations (cvs snapshot from
> > yesterday).
>
> Hmm... on second look, ignore my pr
Stephan Jaeger <[EMAIL PROTECTED]> wrote:
> Testing the newest freerad version i ran into some problems with the
> server crashing under very-high-load situations (cvs snapshot from
> yesterday).
Hmm... on second look, ignore my previous message.
> If you need the complete output or anything el
Stephan Jaeger <[EMAIL PROTECTED]> wrote:
> Testing the newest freerad version i ran into some problems with the
> server crashing under very-high-load situations (cvs snapshot from
> yesterday).
...
> Assertion failed in request_list.c, line 216
Just delete that line.
Alan DeKok.
-
List in
Hi,
Testing the newest freerad version i ran into some problems with the
server crashing under very-high-load situations (cvs snapshot from
yesterday).
rad_recv: Access-Request packet from host 127.0.0.1:42420, id=41,
length=64
User-Name = "test"
User-Password = "xxx"
NAS-
26 matches
Mail list logo
