Just in case this can help you, take a look at http://linux-mm.org/OOM_Killer
Basically the linux kernel has mechanism to kill processes when it runs out of memory. In this case kill signal should not be SIGTERM but googling I found it may be possible in some cases the kernel use this signal. Search in your kernel logs (/var/log/dmesg) to see if you have something like "invoked oom-killer" Regards Luciano 2009/3/31 韩枫 <[email protected]>: > sorry, it includes the prepaid module that i write. u can not reproduce. > > test shell > ------------------------ > #!/bin/bash > i=0 > while true > do > date > time ../radclient -p 16 -q -s -t 3 -r 3 -f auth_test 127.0.0.1:1812 auth > xxxxxx > i=`expr $i \+ 1` > echo $i > done > ---------------------------- > auth_test > User-Name=test1, User-Password=111111, Calling-Station-Id=192.168.10.1 > ,NAS-IP-Address=192.168.0.1, NAS-Port=1, Service-Type=Framed, > Framed-Protocol=PPP > User-Name=test2, User-Password=111111, Calling-Station-Id=192.168.10.1 > ,NAS-IP-Address=192.168.0.1, NAS-Port=2, Service-Type=Framed, > Framed-Protocol=PPP > User-Name=test3, User-Password=111111, Calling-Station-Id=192.168.10.1 > ,NAS-IP-Address=192.168.0.1, NAS-Port=3, Service-Type=Framed, > Framed-Protocol=PPP > User-Name=test4, User-Password=111111, Calling-Station-Id=192.168.10.1 > ,NAS-IP-Address=192.168.0.1, NAS-Port=4, Service-Type=Framed, > Framed-Protocol=PPP > User-Name=test5, User-Password=111111, Calling-Station-Id=192.168.10.1 > ,NAS-IP-Address=192.168.0.1, NAS-Port=5, Service-Type=Framed, > Framed-Protocol=PPP > ... > --------------------------- > > i am testing, possible the same code have not the problem on Centos 5.2 X86. > CENTOS 5.2 X86_64 have the problem. > >> Date: Mon, 30 Mar 2009 16:17:02 -0300 >> Subject: Re: What can cause the "Exiting normally" without prompting >> From: [email protected] >> To: [email protected] >> >> 2009/3/29 韩枫 <[email protected]>: >> > hi, >> > os is centos 5.2 x64,pgsql is 8.3.7. i have not set the cpu quotas. >> > Even, I do not know how to set up cpu quotas. >> > -------------------------------------------------------------- >> > # ulimit -a >> > core file size (blocks, -c) unlimited >> > data seg size (kbytes, -d) unlimited >> > scheduling priority (-e) 0 >> > file size (blocks, -f) unlimited >> > pending signals (-i) 139264 >> > max locked memory (kbytes, -l) 32 >> > max memory size (kbytes, -m) unlimited >> > open files (-n) 8192 >> > pipe size (512 bytes, -p) 8 >>! > POSIX message queues &nb! sp; (bytes, -q) 819200 >> > real-time priority (-r) 0 >> > stack size (kbytes, -s) 10240 >> > cpu time (seconds, -t) unlimited >> > max user processes (-u) 139264 >> > virtual memory (kbytes, -v) unlimited >> > file locks (-x) unlimited >> > >> > -------------------------------------------------------------- >> > Whether or not the changed module will cause this to happen? >> > >> >> Date: Sat, 28 Mar 2009 08:25:48 -0700 >> >> From: [email protected] >> >> To: [email protected] >> >> Subject: Re: What can cause the "Exiting normally" without prompting >> >> >> >> [email protected] wrote: >> >> > i am testing freeradius 2.1.X by radclient , when the number of >> >> > requests arrive 6million+, freeradius will "Exiting normally" >> >> > without> >> > prompting. >> >> >> >> The only time it exits is when something tells it to exit. e.g. via >> >> SIGTERM. >> >> >> >> I've never seen it exit like that in any of my performance tests. >> >> Maybe you have CPU quotas for the server? >> >> >> >> Could you give more details about how to reproduce the situation? >> >> Thanks >> Luciano >> >> - >> List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/users.html > > ________________________________ > 微软地图实时路况，为您节省的不仅仅是时间！ 立即查看！ > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
