[checkmk-commits] [tribe29/checkmk] b7eedf: Synched master and 2.0.0 branches.

Branch: refs/heads/2.0.0 Home: https://github.com/tribe29/checkmk Commit: b7eedf70a678669e6be84db6d1f4c980cc0fc488 https://github.com/tribe29/checkmk/commit/b7eedf70a678669e6be84db6d1f4c980c… Author: Sven Panne <sven.panne(a)tribe29.com> Date: 2021-02-12 (Fri, 12 Feb 2021) Changed paths: M livestatus/src/NagiosCore.cc M livestatus/src/TableStatus.cc M livestatus/src/test/DummyNagios.cc Log Message: ----------- Synched master and 2.0.0 branches. Change-Id: I1f04f71ca2c2c043664af23a4510f1d696748f44 Commit: 46c6da8041d960babb329d827cddc4ea759184dd https://github.com/tribe29/checkmk/commit/46c6da8041d960babb329d827cddc4ea7… Author: Lars Michelsen <lm(a)tribe29.com> Date: 2021-02-12 (Fri, 12 Feb 2021) Changed paths: A .werks/12128 M livestatus/api/python/livestatus.py Log Message: ----------- 12128 FIX Fix random encrypted livestatus connection issues without Livestatus proxy When using encrypted livestatus connections for accessing remote sites while not using the livestatus proxy daemon, this could result in errors like "attempt to connect already-connected SSLsocket" or some handshake related errors like "The handshake operation timed out". This was caused by the livestatus.py client which tries to optimize the connect timeouts by first starting with a very small timeout and then retrying with a larger timeout value. This worked as expected for not encrypted connections, but not for encrypted connections which were able to perform the connect but not the TLS handshake in time. The second try was then failing because of the already connected socket from the first try. This already connected socket is now handled correctly and will retry the handshake with a longer timeout. Change-Id: I96dd50e6e88c14701cd5f17f6301edc78fe7e4d3 Compare: https://github.com/tribe29/checkmk/compare/d8022c2d1bc4...46c6da8041d9