This long-standing part of our container liveness checks seems to be broken on Docker for Mac from at least beta 14 onwards:
new Socket(ipAddress, port).close();
The original behaviour of this was to simply verify that the relevant TCP port was listening, catching an IOException if the container was not listening yet. However, now Docker for Mac seems to be running its own perpetually listening TCP proxy that accepts the connection regardless of whether there is actually a listening process inside the container.
e.g. outside of testcontainers, this demonstrates the behaviour:
$ docker run -p 8080 -d alpine:latest sh -c "yes | nc -l -p 8080" # real listening process inside container
$ docker run -p 8080 -d alpine:latest sh -c "yes > /dev/null" # port mapped, but not listening
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c77d07ba926c alpine:latest "sh -c 'yes | nc -l -" About a minute ago Up About a minute 0.0.0.0:32822->8080/tcp small_mirzakhani
871c2c80ceaf alpine:latest "sh -c 'yes > /dev/nu" 6 minutes ago Up 6 minutes 0.0.0.0:32821->8080/tcp tender_raman
$ lsof | grep LISTEN
[.. snip ..]
com.docke 1481 rnorth 11u IPv4 0x90cfe27e6cde7eb3 0t0 TCP *:32821 (LISTEN)
com.docke 1481 rnorth 13u IPv4 0x90cfe27e6a3ab7ab 0t0 TCP *:32822 (LISTEN)
This seems to make the current wait check too dumb!
I'd be keen to know if others are experiencing this.
I suspect the fix should include opening an inputstream and verifying that the first read doesn't indicate end-of-stream, but I'd like to do some checking to be sure that this doesn't have unintended consequences.
This long-standing part of our container liveness checks seems to be broken on Docker for Mac from at least beta 14 onwards:
The original behaviour of this was to simply verify that the relevant TCP port was listening, catching an IOException if the container was not listening yet. However, now Docker for Mac seems to be running its own perpetually listening TCP proxy that accepts the connection regardless of whether there is actually a listening process inside the container.
e.g. outside of testcontainers, this demonstrates the behaviour:
This seems to make the current wait check too dumb!
I'd be keen to know if others are experiencing this.
I suspect the fix should include opening an inputstream and verifying that the first read doesn't indicate end-of-stream, but I'd like to do some checking to be sure that this doesn't have unintended consequences.