good day all,i have an issue where for a small subset of requests issued during a graceful-stop the client is not receiving connection refused (immediate [RST,ACK] after [SYN]), nor receiving a full response, but the client is rather completing the handshake, receiving an [ACK] after being allowed to send the full request, but then receiving a [RST,ACK] immediately after that [ACK].
as a result, a client with direct access reports 'connection reset by peer', a client with access through a L4 load balancer reports 'empty reply from server' and a client accessing via a reverse proxy receives a 502. all of these seem to be consistent with the observed behavior of abruptly closing the connection.
i have the tcpdumps and the strace output to accompany the above behavior, but before deluging the list with attachments, i wanted to first see
a) if anyone has experienced similar behavior during graceful-stopb) if anyone can point me to an explanation of this behavior (and let me know where my search skills are lacking :-))
c) if it is my understanding of the expected behavior of graceful-stop is at fault here
the particulars of my setup: Debian GNU/Linux 11 (bullseye) apache2: 2.4.56-1~deb11u2, prefork MPM, mod_perlmy testing involves starting a series of curl loops in parallel, then calling graceful-stop on the running server.
client:
~$ for i in {1..6}; do for j in {1..1000}; do curl ...; done; done
server:
~$ apache2ctl graceful-stop && sleep 5 && systemctl start apache2
and the above behavior can usually be observed for a handful of requests
during each test run. and from comparing the strace and tcpdump output,
in _appears_ that the connection is being dropped between the time that
it is received by the parent apache process, but before one of the child
processes can accept() it. ie, for the ephemeral port used for the
errant connections, there is no matching accept() in any of the strace
output.
i hope that i have provided enough initial information and a sufficient description. thanks in advance for any help, pointers or correction.
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|