Le 20/11/2023 à 20:23, Marno Krahmer a écrit :
Hello,
since a while I see connection errors in my HAProxy-Logs, looking like this:
<134>Nov 20 13:19:10 haproxy[8]: <redacted>:60923 [20/Nov/2023:13:18:41.494]
http~ nextcloud/nextcloud 0/0/18/-1/28956 500 208 - - IH-- 19/19/0/0/0 0/0
{<redacted>} "PUT
https://<redacted>/remote.php/dav/uploads/<redacted>/5D56BCEB-AE7E-423A-B424-DCAB3F98C590/3 HTTP/2.0"
According to the documentation, a termination state of "I" should never happen
and be reported together with logs.
Now my Problem is: I don't have any more logs, besides that one line being
logged.
Therefore my question: What can I do to get further information about when/why
this occurs?
Hi,
A 500-Internal-error with "IH--" termination state is not common. AFAIK, It is
an issue when HAProxy tries to format the request before pushing it to the
server, in th H1 multiplexer. It happens ~29s after the beginning of the
request. So it should be an issue with the request payload. It may be because
the payload is larger or smaller than announced. At this stage it is surprising
because it was already accepted on the client side.
You can try to enable the H1 traces at the error level, hoping the error rate
for other reasons is not too high.
You can add this snippet after your global section:
ring buf1
size 104857600 # 10MB
format timed
backing-file /tmp/blah
global
expose-experimental-directives
trace h1 sink buf1
trace h1 level error
trace h1 verbosity complete
trace h1 start now
This will write the H1 error traces in /tmp/blah file. You can show the traces
by running:
strings /tmp/blah | less
If it does not work, you may use haring tool from HAProxy sources. To do so, you
should compile it (make dev/haring/haring). Then run
./dev/haring/haring -f /tmp/blah | less
--
Christopher Faulet
