This looks related to https://bugs.php.net/bug.php?id=79501.

OT: it has to be related.. it was posted on the very same day - 2 years ago ;-)

Just FYI I have got this on my list with relatively high priority. Although there's bunch of other things so it might take few months to get this resolved.

Thanks for the update, let me know if there's something I can do to make duplication easier.

I assume it's this, right? phpredis/phpredis#1726 . After reading it, it seems that it's specific to TLS 1.3. Can you confirm that it's just related to TLS 1.3? Also does this happen with the latest Redis server version?

I ran this to check if tls version matters:

<?php

set_error_handler(function($errno, $errstring, $errfile, $errline, $errcontext) {
        var_dump(get_resources());
        exit(1);
});
$socket = stream_socket_client("tlsv1.2://redis:6379", $error_code, $error_message, 0.2, STREAM_CLIENT_CONNECT | STREAM_CLIENT_PERSISTENT, stream_context_create(['tls' => ['verify_peer_name' => false]]));
echo "here";

Sorry, this is long. tl;dr: I am proposing that the internals stream code should close connections where the tls handshake has timed out before emitting a warning.

For some context, I don't think the issue I'm seeing is the same as phpredis/phpredis#1726
How we found this issue was that we're moving to redis as a session store. We're using persistent connections to limit the number of new connections that need to be created, however, we still sometimes see bursts of new fpm workers coming online, triggering 500 or more new tls-enabled connections to redis. Redis does not like this. It starts to bog down, and ssl connections start to take longer and longer, eventually hitting our timeout (which we set somewhat aggressively at .2 seconds). In this case, the timeout is not a bug with php or redis, but a capacity problem at the redis server. But there is some strange behavior, in that the connections where phpredis hit the timeout while negotiating the tls handshake, are not closed until the fpm process exits. This meant each new request created a new connection, failed tls, but left that connection open, resulting in 20k open connections on a redis host.

This was because the stream internals code emits a warning when the tls handshake times out, and then returns the connection to the phpredis extension, and the phpredis extension attempts to work with the connection, notices communication problems, and closes the connection, except if an error handler exists that stops execution in the case of warnings. In that case, the connection is not closed.

I took a closer look on this one and the problem is basically that there is an area of code in _php_stream_xport_create (specifically everything after stream is created and freed:

I think it's not very practical handle it in every function that triggers error but instead store the errors and emit them later (after freeing the stream). The good thing that we have got already in core (used for inheritance) some functionality to record errors so I will take a look if we could modify that slightly so we can do just record and then reply it after the stream is cleaned up.

Just for the record, the fix should be part of 8.1.10 . It's unfortunately non trivial task to back port the changes to 8.0 in an ABI compatible way as it relies on additions in 8.1 so it won't be part of 8.0.

Thank you for the fix here!

Hi @bukka
Why not use zend_try and zend_catch to solve this problem? This patch (d052742) makes Swoole/Swow can not work anymore, because Coroutine will yield to another one during socket operation, and EG(record_errors) assertion will always fail.
Before that, zend_begin_record_errors was only used during compile time, this patch kills extensions like Swoole/Swow...

Ah yeah forgot about generators. You right I should have used zend_try, zend_catch, zend_bailout here as that's what is used elsewhere. It's just the test is a bit harder but might actually do an FPM test for this which should work.