Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alpine + Swoole + PgSQL on the host = could not send SSL negotiation packet: Resource temporarily unavailable #5313

Open
flexchar opened this issue May 5, 2024 · 15 comments

Comments

@flexchar
Copy link

flexchar commented May 5, 2024

Since the issue is so mysterious, I was able to and made a reproducible. Please try it yourself.

https://github.com/flexchar/pdo-pgsql-issue


Please answer these questions before submitting your issue.

  1. What did you do? If possible, provide a simple script for reproducing the error.
    I attempt to connect to the pgsql running on my host mac machine from inside docker container running Laravel. It would fail with SQLSTATE[08006] [7] could not send SSL negotiation packet: Resource temporarily unavailable error.

It does work if I would connect using psql cli terminal. It also works if I used pg_connect instead php-pdo.

I cannot test with php83 since the latest swoole pecl upstream has been broken for months now. I am not sure what's going on.

  1. What did you expect to see?
    It should connect.

  2. What did you see instead?
    SQLSTATE[08006] [7] could not send SSL negotiation packet: Resource temporarily unavailable

  3. What version of Swoole are you using (show your php --ri swoole)?

Swoole => enabled
Author => Swoole Team <team@swoole.com>
Version => 5.1.1
Built => Nov 28 2023 19:24:57
coroutine => enabled with boost asm context
epoll => enabled
eventfd => enabled
signalfd => enabled
spinlock => enabled
rwlock => enabled
sockets => enabled
openssl => OpenSSL 3.1.4 24 Oct 2023
dtls => enabled
http2 => enabled
json => enabled
curl-native => enabled
c-ares => 1.27.0
zlib => 1.3
brotli => E16781312/D16781312
mutex_timedlock => enabled
pthread_barrier => enabled
mysqlnd => enabled
async_redis => enabled
coroutine_pgsql => enabled
coroutine_sqlite => enabled

Directive => Local Value => Master Value
swoole.enable_coroutine => On => On
swoole.enable_library => On => On
swoole.enable_fiber_mock => Off => Off
swoole.enable_preemptive_scheduler => Off => Off
swoole.display_errors => On => On
swoole.use_shortname => On => On
swoole.unixsock_buffer_size => 8388608 => 8388608

as installed from https://pkgs.alpinelinux.org/packages?name=php82-pecl-swoole&branch=v3.19&repo=community&arch=x86_64&maintainer=

  1. What is your machine environment used (show your uname -a & php -v & gcc -v) ?
$ uname -a
Linux 031104a4b74c 6.6.22-linuxkit #1 SMP Fri Mar 29 12:21:27 UTC 2024 aarch64 Linux

$ php -v
PHP 8.2.18 (cli) (built: Apr 11 2024 14:41:12) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.2.18, Copyright (c) Zend Technologies

$ gcc -v
ash: gcc: not found

It may also be that pdo-pgsql is broken but I am not sure where to report it. I would appreciate the guidance. Thank you. :)

@flexchar flexchar changed the title Unable to connect to pgsql on the host when swoole installed Alpine + Swoole + PgSQL on the host = could not send SSL negotiation packet: Resource temporarily unavailable May 5, 2024
@NathanFreeman
Copy link
Member

NathanFreeman commented May 9, 2024

It seems that I need to synchronize the code for php8.3 pdo_pgsql.

@flexchar
Copy link
Author

flexchar commented May 9, 2024

Swoole unfortunately doesn't work with PHP 8.3 on Alpine because the most recent published version is the one with the bug 5.1.1. Alpine maintains only the most recent version and it's related to the PECL problem. Ref #5242

@myxingkong
Copy link

I encountered the same problem on Debian, and the issue persists after attempting to upgrade PHP to 8.3.

$ uname -a
Linux 2a9a37e4e7c4 6.7.11-orbstack-00143-ge6b82e26cd22 #1 SMP Sat Mar 30 12:20:36 UTC 2024 aarch64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 12 (bookworm)
Release:	12
Codename:	bookworm

$ php -v
PHP 8.3.6 (cli) (built: Apr 24 2024 19:23:57) (NTS)
Copyright (c) The PHP Group
Zend Engine v4.3.6, Copyright (c) Zend Technologies
    with Zend OPcache v8.3.6, Copyright (c), by Zend Technologies

$ php --ri swoole
Swoole => enabled
Author => Swoole Team <team@swoole.com>
Version => 5.1.2
Built => May 14 2024 03:45:52
coroutine => enabled with boost asm context
epoll => enabled
eventfd => enabled
signalfd => enabled
cpu_affinity => enabled
spinlock => enabled
rwlock => enabled
sockets => enabled
openssl => OpenSSL 3.0.11 19 Sep 2023
dtls => enabled
http2 => enabled
json => enabled
curl-native => enabled
pcre => enabled
c-ares => 1.18.1
zlib => 1.2.13
mutex_timedlock => enabled
pthread_barrier => enabled
futex => enabled
async_redis => enabled
coroutine_pgsql => enabled

Directive => Local Value => Master Value
swoole.enable_coroutine => On => On
swoole.enable_library => On => On
swoole.enable_fiber_mock => Off => Off
swoole.enable_preemptive_scheduler => Off => Off
swoole.display_errors => On => On
swoole.use_shortname => On => On
swoole.unixsock_buffer_size => 8388608 => 8388608

@flexchar
Copy link
Author

Same here on alpine with the new version. The thing that sucks is that alpine only has the latest versions which now makes everyone stuck with the broken one. I tried switching to FrankenPHP but Swoole outperforms it by 30x in my humble benchmarks. So it's also hard to say no.

@NathanFreeman
Copy link
Member

@myxingkong Can you provide a script for reproduction?

@NathanFreeman
Copy link
Member

@flexchar Do you have coroutines enabled?

@flexchar
Copy link
Author

flexchar commented May 14, 2024

@NathanFreeman If this is the fair way to judge, then it seems so.

(Note this is the output from the working version)

laravel@:/var/www $ php --ri swoole

swoole

Swoole => enabled
Author => Swoole Team <team@swoole.com>
Version => 5.0.3
Built => May 11 2023 21:36:59
coroutine => enabled with boost asm context
epoll => enabled
eventfd => enabled
signalfd => enabled
spinlock => enabled
rwlock => enabled
sockets => enabled
openssl => OpenSSL 3.1.0 14 Mar 2023
dtls => enabled
http2 => enabled
json => enabled
curl-native => enabled
c-ares => 1.19.1
zlib => 1.2.13
brotli => E16777225/D16777225
mutex_timedlock => enabled
pthread_barrier => enabled
mysqlnd => enabled
async_redis => enabled

Directive => Local Value => Master Value
swoole.enable_coroutine => On => On
swoole.enable_library => On => On
swoole.enable_preemptive_scheduler => Off => Off
swoole.display_errors => On => On
swoole.use_shortname => On => On
swoole.unixsock_buffer_size => 8388608 => 8388608

I tried setting them off using the following but the issue remains the same.

[swoole]
swoole.enable_coroutine = 0

@myxingkong
Copy link

If coroutines are not used, connecting to external servers will not work properly. However, there is no problem connecting to the internal Docker server.

$dsn = 'pgsql:dbname=postgres host=192.168.199.201 port=5432';
try {
    $db = new PDO($dsn, 'postgres', '123456');
    echo "Connected successfully";
} catch (PDOException $e) {
    echo "Connection failed: " . $e->getMessage();
}

Output:

Connection failed: SQLSTATE[08006] [7] could not send SSL negotiation packet: Resource temporarily unavailable

Moving the above code into a coroutine, it can work normally.

use function Swoole\Coroutine\run;

run(function () {
    $dsn = 'pgsql:dbname=postgres host=192.168.199.201 port=5432';
    try {
        $db = new PDO($dsn, 'postgres', '123456');
        echo "Connected successfully";
    } catch (PDOException $e) {
        echo "Connection failed: " . $e->getMessage();
    }
});

Output:

Connected successfully

After attempting to disable coroutines, the problem still exists. Only when I completely disable the Swoole extension, can the problem be solved.

@never615
Copy link

never615 commented May 22, 2024

php -v

same problem on Debian
截屏2024-05-22 21 38 29
截屏2024-05-22 21 39 21

swoole 5.1.1 php8.2;
swoole 5.1.2 php8.2;
swoole 5.1.2 php8.3; I have tested these versions and have the same problems on debian. Test based on phpswoole/swoole docker image.

on Ubuntu,It is ok. (swoole 5.1.1 php8.3.6)

@vic-pic
Copy link

vic-pic commented May 29, 2024

Hi,
I have the same problem with all versions starting from version 5.1, with debian and alpine, with php 8.2 and 8.3.
I'm using official swoole docker images.
With official docker images of swoole 5.0 everything works correctly.

@NathanFreeman
Copy link
Member

NathanFreeman commented May 29, 2024

I have tried many methods,

  1. php, swoole, and postgresql are directly installed on the server.
  2. php, swoole installed in a docker, postgresql on the server.
  3. php, swoole in docker A, postgresql in docker B.

None of which can be reproduced.
Is there any other information that can be provided?
@never615 @vic-pic @myxingkong @flexchar

@NathanFreeman
Copy link
Member

Or execute php -m to check if php has installed pdo_pgsql.

@flexchar
Copy link
Author

@NathanFreeman,
it works if both are on the same level such as on the server or inside docker containers in the same stack. However not if swoole inside docker and pgsql on the host - your variant number 2.

Did you try the 2nd using the docker image I provided? I used Postrgres.App on mac as the database on the host and in this scenario it will cause the error.

@vic-pic
Copy link

vic-pic commented May 29, 2024

@NathanFreeman ,
my case is that I'm running pgsql on the host machine, and it doesn't work. The same Dockerfile used to build container with swoole 5.1 that doesn't work, with swoole 5.0 works without problems.

@allsilaevex
Copy link

@NathanFreeman

If I run Swoole v5.1.2 and PostgreSQL v15.2 on the same network via docker compose, then everything works fine. But if I assign swoole the network "net1", and postgresql the network "net2", then I get an error "could not send SSL negotiation packet".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants