[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 11:36 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.
====================================================================== 

---------------------------------------------------------------------- 
 (0120766) dbackeberg (reporter) - 2010-04-22 11:36
 https://issues.asterisk.org/view.php?id=17223#c120766 
---------------------------------------------------------------------- 
So my conclusion of the SVN escapade was that while the structure of the
function in question is changed, my testing has shown that it still suffers
from the same problems as release 1.6.2.6. The Fleming patch fixes both SVN
and 1.6.2.6.

[root at fivr03 asterisk-1.6.2.6-svn-branch]# diff -u
1.6.2.modified.by.dave/main/app.c 1.6.2/main/app.c 
--- 1.6.2.modified.by.dave/main/app.c	2010-04-22 10:38:25.000000000 -0400
+++ 1.6.2/main/app.c	2010-04-22 11:13:13.000000000 -0400
@@ -2018,8 +2018,7 @@
 	} else {
 		getrlimit(RLIMIT_NOFILE, &rl);
 		null = open("/dev/null", O_RDONLY);
-		for (x = n + 1; x < 4096; x++) { 
-/*		for (x = n + 1; x < rl.rlim_cur; x++) { */
+		for (x = n + 1; x < rl.rlim_cur; x++) {
 			if (x != null) {
 				/* Side effect of dup2 is that it closes any existing fd without
error.
 				 * This prevents valgrind and other debugging tools from sending up 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-22 11:36 dbackeberg     Note Added: 0120766                          
======================================================================