[
https://issues.apache.org/jira/browse/MESOS-9911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16895558#comment-16895558
]
Till Toenshoff commented on MESOS-9911:
---------------------------------------
We do actually check {{errno}} using {{EVUTIL_SOCKET_ERROR()}} which returns
the former - if that returns non zero, we do use
{{evutil_socket_error_to_string}} with that value - a {{strerror}} wrapper. So
it appears as if there can be circumstances in which {{BEV_EVENT_ERROR}} was
set in the event map, {{errno}} was zero but we still receive an
{{SSL_ERROR_SYSCALL}}. Maybe this was really just a quirk of my complete
linkage failure and nothing we need to pay more attention to.
> SSL socket error logging can be improved.
> -----------------------------------------
>
> Key: MESOS-9911
> URL: https://issues.apache.org/jira/browse/MESOS-9911
> Project: Mesos
> Issue Type: Bug
> Affects Versions: 1.9.0
> Reporter: Till Toenshoff
> Priority: Minor
> Labels: OpenSSL, foundations, libevent, libprocess
>
> While debugging some unrelated linkage problem, I noticed the following error
> output;
> {noformat}
> 16:19:25 I0728 16:19:25.323794 26188 libevent_ssl_socket.cpp:1244] Socket
> error: error:00000005:lib(0):func(0):DH lib
> {noformat}
> The error message appears not very helpful and that we can improve on.
> When receiving a libevent openssl-error, we do not check the error code but
> pass it on to openssl for retrieving an error string -- this is not ideal
> considering that openssl does signal more;
> The error code 5, which actually means {{SSL_ERROR_SYSCALL}} does hint that
> we should now check {{errno}} for more information on the problem. We should
> only ever invoke openssl's error string generator when we did receive a
> {{SSL_ERROR_SSL}}.
> Also see
> http://openssl.6102.n7.nabble.com/SSL-read-return-1-error-00000005-lib-0-func-0-DH-lib-tp27612p27613.html
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
