[asterisk-dev] asterisk 1.4 rtp port exhaustion fix

[Paul Albrecht]

On Mon, 2011-05-16 at 16:42 -0500, Tilghman Lesher wrote:
> On Monday 16 May 2011 15:26:29 Paul Albrecht wrote:
> > On Mon, 2011-05-16 at 13:53 -0500, Paul Belanger wrote:
> > > On 11-05-16 02:02 PM, Paul Albrecht wrote:
> > > > Hi,
> > > > 
> > > > When I run the mp3 application I sometimes run out of rtp ports
> > > > because asterisk doesn't close open files and sockets before
> > > > exec'ing the mpg123
> > > 
> > > > process. Here's a fix:
> > > If there is not already an issue on the tracker, please create one.
> > > Also, uploading your patch to reviewboard would be recommended.
> > 
> > There must be an issue already because someone "fixed" the problem for
> > later asterisk releases. The thing is I don't think the "fix" makes
> > sense for linux which I thought was the preferred platform for asterisk.
> > The linuxy way to close open descriptors before exec'ing a script would
> > be to set the "close on exec" whenever a file is opened or a socket is
> > created. As for the review board, I simply fixed the stuff that affected
> > the applications that I support so the codes not finished and not ready
> > for review.
> 
> We opted in the later releases to make it part of the API and standardize
> the various methods to ensure that all file descriptors were closed (as well
> as fixing signal races and other issues).  No, it's not Linux-specific, but
> it should work fine on all platforms where fork is available (as opposed to
> vfork).
> 
> As to the CLOEXEC method, it's very difficult to make that method work
> reliably, because many calls that open file descriptors do not have flags
> to ensure that the CLOEXEC flag is set atomically.  Additionally, linked
> libraries may open file descriptors at various intervals, and it would be
> impossible to ensure that each of those libraries also used the CLOEXEC
> flag.  It was definitely considered at the time, but it was rejected, because
> it's not a reliable method.
> 

Don't know what you mean when you say the "close on exec" flag is
unreliable. Can you point out which code sequences you think are
problematic in the patch I submitted to this list?

-- 
Paul Albrecht