Asterisk -rx command take long time to return back

hi, after install asterisk 11.25, and i input “asterisk -rx XXXXX” to add some dialplan ,but it took a long time to execute,about 2 seconds. this happened on a virtual .machine。 normal it will return back less than 0.1s…can somebody help???thx.

Depends on what XXXXX was!

have you tried with a more recent version
as asterisk 11 have been EOL for at least 4 years

we had add some applications on 11.25…so can not update to 16 or later…

all asterisk -rx command takes long time to return…
like asterisk -rx ‘core show calls’
asterisk -rx ‘dialplan add t,1,hangup() into from-sip replace’
even asterisk -rx the command itself…

(It’s been a really long time since I’ve used 11, so please excuse me if I suggest a command that is syntactically incorrect for 11. Please translate as needed.)

Does ‘pinging’ the VM take longer than reasonable?

Is the VM host overloaded?

Do the symptoms change if you purge iptables?

Try something really simple and cheap resource-wise. How about:

time sudo /sbin/asterisk -x 'core show version'


time sudo /sbin/asterisk -x 'core show uptime'

(Note that ‘-r’ is implied when using ‘-x.’)

If these take more that a couple hundredths of a second, does executing:

sudo tcpdump -A -i any -s 0

on either your host or on the VM* while executing the above commands yield any clues? Any DNS requests you’re not expecting? Any chance your resolvers are unavailable? How long does it take to get a DNS response?

Does executing the above commands directly from the Asterisk CLI change the ‘delay?’

*) Appending ‘not port 22’ may be useful.

1 Like

thx sedwards.

here i tried: ping the vm and dns or localhost is very fast,lest than 0.01s
and the vm is a new machine,has 4C16G ,the asterisk is new install .also i reinstall several times,the result is the same.

i tried asterisk -x ‘core show version’
or /sbin/asterisk -x ‘core show uptime’ the return is slow ,
but executing the above commands directly from the Asterisk CLI is super fast.

i’ll try tcpdump that you tell above.

”tcpdump -A ‘!port 22’ -i any -s 0 “ command got nothing when i execute
/sbin/asterisk -x ‘core show version’

can any other support me?

it is going to be limited with how much help that you can get
as you are using an outdated and modified version

for testing where the problem is, can you try the following
test an unmodified asterisk 11.25 (to see where it is your changes or not)
if you still experience problem
test with the latest version of asterisk
when it is working again, you can look at what you need to do to add your modifications

test an unmodified asterisk 11.25 is good, and no problem…
but the modified asterisk work well on other machine.
can some one explain how does "asterisk -rx " work? may be the command need to do some work under grand…

The OS loads Asterisk. Asterisk then looks in a standard place for a Unix domain socket and sends the -x argument down the pipe, then reads the responses back from the socket.

That means it will load the Asterisk code, although that should have been built as position independent, so it will actually just map the same pages as in the main copy of Asterisk. There may still be page-ins because of pages not being used during normal operation of Asterisk. It will also still have to create copies of pages that are read-write, although the OS will probably do that the first time they are written to. There will be some initialisation code run, and it is possible that will involve DNS resolution of the system’s own address, but might not as it shouldn’t be necessary in this case.

Depending on how you launch it, you may end up first loading a shell, e.g. system(3) will do that.

Generally launching a program to process one commend tends to be an expensive thing to do.

Run the command using strace. It could show which system call is making slowdown.

i will try the strace command,thx
it works.find it was the network config name different…to delay the start.don’t know why.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.