[asterisk-bugs] [Asterisk 0017223]: [patch] System() taking excessive time to return with nonroot
Asterisk Bug Tracker
noreply at bugs.digium.com
Fri Apr 30 01:22:15 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=17223
======================================================================
Reported By: dbackeberg
Assigned To: tilghman
======================================================================
Project: Asterisk
Issue ID: 17223
Category: Applications/app_system
Reproducibility: always
Severity: tweak
Priority: normal
Status: closed
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:
Resolution: fixed
Fixed in Version:
======================================================================
Date Submitted: 2010-04-21 14:37 CDT
Last Modified: 2010-04-30 01:22 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.
======================================================================
----------------------------------------------------------------------
(0121208) svnbot (reporter) - 2010-04-30 01:22
https://issues.asterisk.org/view.php?id=17223#c121208
----------------------------------------------------------------------
Repository: asterisk
Revision: 260303
_U branches/1.6.2/
U branches/1.6.2/main/app.c
------------------------------------------------------------------------
r260303 | tilghman | 2010-04-30 01:22:14 -0500 (Fri, 30 Apr 2010) | 18
lines
Merged revisions 260292 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk
........
r260292 | tilghman | 2010-04-30 01:19:35 -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.
(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=260303
Issue History
Date Modified Username Field Change
======================================================================
2010-04-30 01:22 svnbot Checkin
2010-04-30 01:22 svnbot Note Added: 0121208
======================================================================
More information about the asterisk-bugs
mailing list