[asterisk-bugs] [Asterisk 0017223]: [patch] System() taking excessive time to return with nonroot

[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-30 01:19 CDT
====================================================================== 
Summary:                    [patch] System() taking excessive time to return
with nonroot
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.
====================================================================== 

---------------------------------------------------------------------- 
 (0121207) svnbot (reporter) - 2010-04-30 01:19
 https://issues.asterisk.org/view.php?id=17223#c121207 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 260292

U   trunk/main/strcompat.c

------------------------------------------------------------------------
r260292 | tilghman | 2010-04-30 01:19:36 -0500 (Fri, 30 Apr 2010) | 13
lines

Don't allow file descriptors to go above 64k, when we're closing them in a
fork(2).

This saves time, when, even though the system allows the process limit to
be
that high, the practical limit is much lower.  Also introduce an
additional
optimization, in the form of using the CLOEXEC flag to close descriptors
at
the right time.

(closes issue https://issues.asterisk.org/view.php?id=17223)
 Reported by: dbackeberg
 Patches: 
       20100423__issue17223.diff.txt uploaded by tilghman (license 14)
 Tested by: dbackeberg

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=260292 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-04-30 01:19 svnbot         Checkin                                      
2010-04-30 01:19 svnbot         Note Added: 0121207                          
======================================================================