sequential/test-tls-psk-client fails on IBM i

[richardlau]

With #44215 we're down to one test that is failing the IBM i CI build:

https://ci.nodejs.org/job/node-test-commit-ibmi/862/nodes=ibmi73-ppc64/console

10:21:56 not ok 3714 sequential/test-tls-psk-client # TODO : Fix flaky test
10:26:56   ---
10:26:56   duration_ms: 300.226
10:26:56   severity: fail
10:26:56   exitcode: -15
10:26:56   stack: |-
10:26:56     timeout
10:26:56     Failed: Timed out
10:26:56   ...

This test is already marked flaky on IBM i

node/test/sequential/sequential.status

Lines 30 to 31 in d7f1934

	# https://github.com/nodejs/node/issues/39683
	test-tls-psk-client: PASS, FLAKY

but it looks like the test runner treats timed out tests as failures (severity: fail) instead of flakes (severity: flaky).

Originally posted by @richardlau in #43509 (comment)

[richardlau]

Turns out that this test is failing because the spawn of the CLI openssl tool fails, although that isn't caught/reported:

node/test/sequential/test-tls-psk-client.js

Lines 18 to 26 in 5118c31

	const server = spawn(common.opensslCli, [
	's_server',
	'-accept', common.PORT,
	'-cipher', CIPHERS,
	'-psk', KEY,
	'-psk_hint', IDENTITY,
	'-nocert',
	'-rev',
	]);

If I manually run the openssl-cli command that is being spawned I get this:

Using default temp DH parameters
00000001:error:8000002A:system library:BIO_listen:Protocol driver not attached:../deps/openssl/openssl/crypto/bio/bio_sock2.c:275:calling setsockopt()
00000001:error:10000088:BIO routines:BIO_listen:listen v6 only:../deps/openssl/openssl/crypto/bio/bio_sock2.c:277:
   0 items in the session cache
   0 client connects (SSL_connect())
   0 client renegotiates (SSL_connect())
   0 client connects that finished
   0 server accepts (SSL_accept())
   0 server renegotiates (SSL_accept())
   0 server accepts that finished
   0 session cache hits
   0 session cache misses
   0 session cache timeouts
   0 callback cache hits
   0 cache full overflows (128 allowed)

However using the system OpenSSL CLI gives:

Using default temp DH parameters
ACCEPT

Which leads to:

1. Do we expect the built openssl-cli to work on IBM i? Possibly not going by previous comments, e.g. test: skip some binding tests on IBMi PASE  #31967 (comment) which state that the IBM i port of Node.js always uses shared libs. Our CI job currently does not use shared libs which is a potential mismatch.
2. The test should ideally detect if the openssl server hasn't started and error appropriately. It appears that currently it never terminates in this state as waitForPort spins forever waiting for the server to come up until the test runner times the test out and kills it.

cc @nodejs/platform-ibmi

[V-for-Vasili]

I know that in the node rpm we build with --shared-openssl, so we use the system install. Looks like we use built openssl in https://ci.nodejs.org/job/node-test-commit-ibmi/913/nodes=ibmi73-ppc64/consoleText.
Also, what version is the built openssl-cli? I think 1.1.1 is the latest we support but I need to double check

[richardlau]

Also, what version is the built openssl-cli? I think 1.1.1 is the latest we support but I need to double check

@V-for-Vasili It would be OpenSSl 3.0.x, built from deps/openssl.
FWIW I've started a CI run with CONFIG_FLAGS='--shared-openssl --shared-openssl-includes=/QOpenSys/usr/include --shared-openssl-libpath=/QOpenSys/lib --dest-cpu=ppc64': https://ci.nodejs.org/job/node-test-commit-ibmi/915/

[V-for-Vasili]

Yep, we don't support 3.x on Ibmi, and we use 1.1.1 with the node rpm. 3.x is work in progress currently.

[richardlau]

FWIW I've started a CI run with CONFIG_FLAGS='--shared-openssl --shared-openssl-includes=/QOpenSys/usr/include --shared-openssl-libpath=/QOpenSys/lib --dest-cpu=ppc64': https://ci.nodejs.org/job/node-test-commit-ibmi/915/

Looks like that failed while linking 😞 .

[richardlau]

Further digging on test-iinthecloud-ibmi73-ppc64_be-1 showed that the system openssl command in /QOpenSys/bin/ was 1.0.2q. Installing openssl via yum installs OpenSSL 1.1.1n into /QOpenSys/pkgs/bin/ and that has the same "Protocol driver not attached" error.

Turns out we've seen this before: #42152 (comment)

[richardlau]

(FWIW after #44824 the test no longer times out but fails with the "Protocol driver not attached" error from the call to the openssl CLI (either system when compiled with --shared-openssl or the one built from deps/openssl.)

[abmusse]

#42152 (comment)