Hi Gwen,
it will be safer to uninstall first the 0.8.12 version. out of curiosity, since the problem you reported is quite strange, have you tried db_mod 2?
bogdan
g.billoudet@arwen-tech.fr wrote:
Hi,
If I don't use "serctl alias add", I still get the same error message... I will try to upgrade ser:
- Should I uninstall ser 0.8.12 and then install 0.8.14
- Or should I install 0.8.14 directly ?
Thanks
Gwen
Try to install 0.8.14.
Jan.
On 10-11 14:27, Bogdan-Andrei IANCU wrote:
Hi Gwen,
try to set back db_mode to 1 or 2 but without adding the aliases via serctl. I'm trying to figure out if it's a problem in DB part or in fifo part of usrloc.
bogdan
g.billoudet@arwen-tech.fr wrote:
Hi, thanks for help
I used serctl alias add 1234 sip:gwenael@arwen-tech.fr just after
starting
ser :
- When I set modparam("usrloc", "db_mode", 0), ser works fine and I can
have phone calls but I can't use this alias of course...
- When I ser modparam("usrloc", "db_mode", 1), ser just doesn't work at
all.
My aliases table is empty when I start ser. I am using ser 0.8.12.
Gwen
On 10-11 11:41, Bogdan-Andrei IANCU wrote:
Jan Janak wrote:
>On 10-11 10:01, Bogdan-Andrei IANCU wrote: > > > > >>my first guess is that use at start-up time you have an intensive >>private memory consumer which gets into conflict with the SIP >> >>
messages
>>receiver. >> >>Judging after the error (in receive loop) I'm sure you have some >> >>
SIP
>>traffic at start-up - please check with tcpdump or ngrep - it can >> >>
be
a
>>REGISTER, SUBSCRIBE, etc >> >>Looking into your script, I would say only usrloc can be the >> >>
intensive
>>private memory consumer - if you have a lot of entries in DB >> >>
(usrloc
and
>>aliases). To check this theory, try to start ser with DB disabled >> >>
in
>>usrloc; set: >> modparam("usrloc", "db_mode", 0) >> >>please see if you still get the error and also please confirm if >> >>
you
>>have or not sip traffic. >> >> >I don't think this is the problem. usrloc consumes private memory >before SER forks (and at that stage it does not process SIP > > messages),
>when re-loading data from the database. It would fail to start if > > this
>was the problem, so I think there must be some other memory problem. > > I was considering the possibility of memory fragmentation. If there
are
a lot of usrloc/aliases records to be loaded, memory can get to fragmented to be able later to alloced a bigger size chunk.
Bot tables (aliases, location) are empty:
0(0) preload_udomain(): Table is empty 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup 0(0) preload_udomain(): Table is empty
Jan.