On 02/12/2009 11:23 PM, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
On 02/12/2009 11:11 PM, Alex Balashov wrote:
Brian Chamberlain wrote:
On 12 Feb 2009, at 21:06, Alex Balashov wrote:
Daniel-Constantin Mierla wrote:
Hello, correlating messages: Feb 12 20:27:22 sw1 kernel: [3273100.093090] INFO: task kamailio:22821 blocked for more than 120 seconds. and Process:: ID=14 PID=22821 Type=MI Datagram seems that one of your MI datagram was blocked for some time. Are you using MI datagram commands often? What are they?
Brian, I would guess CDRtool and its rating engine use a lot of MI commands as part of its interface with the proxy. Daniel, can you corroborate that?
I've been doing a lot of rerating today as it goes..
I don't know that this results in a lot of MI commands. I think CDRtool and its processes use a lot of MI for managing session timers and stuff like that, or maybe that's Call Control. I'm not really familiar with AG Projects' technology stack.
OK, so we identified the source. Thanks a lot Alex!
Brian, you could sniff the UDP traffic for MI datagram, are you using UDP sockets or unix sockets?
UNIX domain sockets. I am not aware of a good way to "sniff" those. Is there one?
Never did it, but I found this after a quick googling: http://graag.blogspot.com/2007/10/unix-socket-sniffer.html
I suppose one could switch to UDP sockets...
This is the way I would do, then use ngrep/wiresharck/.... Hopefully the cdrtool supports UDP sockets.
Anyhow, I wonder what the cdrtool would need for rating from kamailio... so if you can get the commands send by cdrtool, I can tell you where is the possible lock.
I do not know.
I've been trying to help Brian with this, but I just don't know enough about the AG Projects end of things.
Neither do I, but we can do reverse engineering if you learn the commands send.
The problem could become critical, if it blocks access to some hash/location in memory for modules (e.g., usrloc).
Cheers, Daniel