El Lunes, 1 de Marzo de 2010, Daniel-Constantin Mierla escribió:
Do you mean running kamailio as usual and later running: gdb> attach KAMAILIO_MASTER_PID ?
yes, run as usual and when it is no longer working attach to a SIP worker process and grab the backtrace.
ok
Could it affect to the performance of the service? If not, when to run "bt"? after the problem occurs?
Yes, after the problem occurs. Only the process you attach to is going to be blocked in gdb, the others should function normally (but they don't anyhow, as I understood).
Yes, no worker works after the problem occurs.
Might be some race in permissions module induced by address_reload MI command.
I suspected it. However it doesn't explain the fact that later kamailio cannot be started again (even after killing all the kamailio processes with -9). Would it make sense?
Is it the fifo/pid file there? No error why is not starting again?
I must check it. Anyhow, as I said it's a very strange problem as some day it occured after reloading the iptables rules! (without changing nothing important). Very very strange, but as it occurs in two servers I want to believe that has something to do with k or rtpproxy version.
I'll prepare a SIPp scenario to check it with some load.
Thanks a lot.