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

---------------------------------------------------------------------- 
 (0120756) dbackeberg (reporter) - 2010-04-22 09:54
 https://issues.asterisk.org/view.php?id=17223#c120756 
---------------------------------------------------------------------- 
Wow, that was dramatic.

So I had two files limits set. 

There's a setting in /etc/asterisk/asterisk.conf,
called 'maxfiles'. Commenting out my change, and leaving it at default had
zero effect.

I've also been forcing a high ulimit, with ulimit. I have an entry in my
/etc/init.d/asterisk that forces a high ulimit. It runs asterisk as a
non-root user, and does for that user, 

echo -n "Setting ulimits:                                              "
ulimit -n 1000000 -c unlimited && echo "OK" || echo "FAILED"

When I comment out that entry, and just use the factory default, I solve
my problem, that is, the System() calls again go lightning fast, even with
released 1.6.2.6

So that begs the question. Should my changes have the effect they are
having? 

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