----------------------------------------------------------- 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 > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
