[asterisk-bugs] [Asterisk 0017223]: System() taking excessive time to return, asterisk-1.6.2.6

Asterisk Bug Tracker noreply at bugs.digium.com
Thu Apr 22 10:30:33 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17223 
====================================================================== 
Reported By:                dbackeberg
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17223
Category:                   Applications/app_system
Reproducibility:            always
Severity:                   tweak
Priority:                   normal
Status:                     feedback
Asterisk Version:           1.6.2.6 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-04-21 14:37 CDT
Last Modified:              2010-04-22 10:30 CDT
====================================================================== 
Summary:                    System() taking excessive time to return,
asterisk-1.6.2.6
Description: 
I've opened a discussion on asterisk-users on April 2010 regarding problems
I've seen with System() calls on asterisk-1.6.2.6. I have a dialplan that
does seemingly bening things that should return lightning fast, like:

exten => s,1,Verbose(EXTENSION is: ${EXTEN})
exten =>
s,n,Set(FIREBREAK_GENERIC=/var/lib/asterisk/sounds/firebreak/catchall)
exten => s,n,System(test -e ${FIREBREAK_GENERIC}.*)
exten => s,n,Verbose(System call result was ${SYSTEMSTATUS})
exten => s,n,ExecIf($[${SYSTEMSTATUS} =
SUCCESS]?Playback(${FIREBREAK_GENERIC}))

The System() call in this example is very straightforward. Use System() to
determine if file exists, if yes, play it.

As a verification that the system call runs fine...
[root at fivr03 ~]# test -e /var/lib/asterisk/sounds/firebreak/catchall.*
[root at fivr03 ~]# echo $?
1
[root at fivr03 ~]# time test -e
/var/lib/asterisk/sounds/firebreak/catchall.*

real	0m0.000s
user	0m0.001s
sys	0m0.000s

However, with stock asterisk-1.6.2.6 on two of my CentOS systems, each
call to System() takes upwards of half a second to return from the call.
Problem was always reproducible on these systems with this dialplan. I have
a third system with asterisk-1.6.2.6 on Gentoo, and I did not have this
problem on that system. I don't know what that means.

Kevin Fleming suggested on asterisk-users to modify main/app.c,
ast_close_fds_above_n() function. 

I have done so, and this solves my problem.
====================================================================== 

---------------------------------------------------------------------- 
 (0120758) dbackeberg (reporter) - 2010-04-22 10:30
 https://issues.asterisk.org/view.php?id=17223#c120758 
---------------------------------------------------------------------- 
>What the SVN version does is to use the /proc filesystem, assuming you
have >one, which you should, to check how many actual file descriptors you
have open >and close each one.

However, I'm reporting that even with SVN, I still have the slow System()
calls unless I patch main/app.c, ast_close_fds_above_n() for loop to force
a fraudulent open files value.

With released 1.6.2.6, setting ulimit lower fixes the slow System() calls,
without having to patch.

With SVN-1.6.2, setting ulimit lower has no effect, and System() calls
remain slow unless I patch.

Specifically, I'm saying that current SVN does not fix my problem, and
that applying the patch DOES fix BOTH 1.6.2.6 and SVN 1.6.2. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-22 10:30 dbackeberg     Note Added: 0120758                          
======================================================================




More information about the asterisk-bugs mailing list