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

[Asterisk Bug Tracker]

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 09:31 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0120752) dbackeberg (reporter) - 2010-04-22 09:31
 https://issues.asterisk.org/view.php?id=17223#c120752 
---------------------------------------------------------------------- 
I gave SVN a try. I'll be specific with the results of my testing. My
dialplan does four calls to System() in rapid succession.

with released asterisk-1.6.2.6, watching my call timer on my SIP phone,
there is a gap of six seconds between the last message playing, and when
the System() calls return so the next message can play.

with Fleming-patched, released asterisk-1.6.2.6, same test, there is less
than a second between with the four System() call start and when the next
message plays.

with SVN, specifically (from 'core show version')
SVN-branch-1.6.2-r258436, I get the same result as released, unpatched,
asterisk-1.6.2.6. That is, I get a capy of six seconds between the last
message playing, and when the System() call s return so the next message
can play. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-22 09:31 dbackeberg     Note Added: 0120752                          
======================================================================