[asterisk-dev] [Code Review] 4380: tcptls: Bad file descriptor error when reloading chan_sip

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4380/#review14319
-----------------------------------------------------------



branches/11/main/tcptls.c
<https://reviewboard.asterisk.org/r/4380/#comment24806>

    I know in your case what was returned was EBADF; however, looking at what all can be returned by accept (http://linux.die.net/man/2/accept), I'm not sure we should continue under other circumstances as well.
    
    * EAGAIN/EWOULDBLOCK - other than we should probably be handling EWOULDBLOCK, we should continue, and already do.
    * EBADF - break. The accept isn't going to work ever.
    * ECONNABORTED - if a single connection aborted, we should go back to accepting. Continue.
    * EFAULT - break. The addr argument is invalid.
    * EINTR - continue, which we already do.
    * EINVAL - break. If the socket isn't listening for connections, accepting again isn't going to matter.
    * EMFILE/ENFILE - break. If we've exceeded our file descriptor limit, things are going to go wrong quickly.
    * ENOBUFS, ENOMEM - break. If we've exceeded the socket buffer limits, we're again going to run into larger issues.
    * ENOTSOCK/EOPNOTSUPP - break. The file descriptor is not what we thought it was.
    * EPROTO - break. I'm not sure why re-trying on a protocol error would be expected to succeed.
    
    Given that, I think this could just be written:
    
    if ((errno != EAGAIN) && (errno != EWOULDBLOCK) && (errno != EINTR)) {
        ast_log(LOG_WARNING, "Accept failed: %s (%d)\n", strerror(errno), errno);
        break;
    }
    continue;


- Matt Jordan


On Jan. 27, 2015, 2:02 p.m., Kevin Harwell wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4380/
> -----------------------------------------------------------
> 
> (Updated Jan. 27, 2015, 2:02 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24728
>     https://issues.asterisk.org/jira/browse/ASTERISK-24728
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> While running through some scenarios using chan_sip and tcp a problem would occur that resulted in a flood of bad file descriptor messages on the cli:
> 
> tcptls.c:712 ast_tcptls_server_root: Accept failed: Bad file descriptor
> 
> The message is received because the underlying socket has been closed, so is valid. This is probably happening because unloading of chan_sip is not atomic. That however is outside the scope of this patch. This patch simply stops the logging of multiple occurrences of that message.
> 
> 
> Diffs
> -----
> 
>   branches/11/main/tcptls.c 431188 
> 
> Diff: https://reviewboard.asterisk.org/r/4380/diff/
> 
> 
> Testing
> -------
> 
> This issue was found while doing some testing. Ran those tests again to make sure that the messages no longer consumed the cli and only printed once.
> 
> 
> Thanks,
> 
> Kevin Harwell
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150127/4b8fc497/attachment.html>