Hi Paul,
That is incredibly weird. Can you tell me what system you're running
this service on? Ideally with the contents of sysdeps/target and
sysdeps/sysdeps (the sysdeps directory can be found under
/usr/lib/skalibs
unless you chose a different installation path).
Can you also provide a strace for the whole command line, including
s6-tcpserver? I'm interested in the line around accept() or accept4(),
when s6-tcpserver(d) receives the connection request and accepts it.
I'm also interested in any occurrence of O_NONBLOCK in the whole trace.
You can dump a full trace on a pastebin and post the URL here, I'll do
the detective work.
Rationale:
- s6-tlsd-io did not print a reason for the handshake failing, which
means it's a system error, not a TLS error. Which is confirmed by your
strace excerpt:
> write(1, "\26\3\3\0z\2\0\0v\3\3\236\31\324\t\203[\363D>[BT\376\250\222.\20_at_\217\335x"..., 3694) = 3694
> read(0, 0x5573be731883, 5) = -1 EAGAIN (Resource temporarily unavailable)
- This seems to say that fd 0, i.e. the socket obtained by
s6-tcpserver,
is nonblocking.
- But that socket is always obtained blocking, and with the libtls
backend, normally remains so until *after* the TLS handshake.
- So there is something somewhere that turns the socket nonblocking
before the handshake, and I don't know what that is; I've never seen
it before, and nothing in the code path should be doing that.
What's happening to the socket, why it's not blocking at handshake
time, is what we're looking for.
--
Laurent
Received on Thu Dec 04 2025 - 04:37:55 CET