Control: tags 1070789 moreinfo Simon McVittie wrote...
> clevis appears to have a "flaky" autopkgtest: that is, an autopkgtest > that usually passes, but is not reliable. (...) > For example see > https://ci.debian.net/packages/c/clevis/testing/amd64/46456138/ > (while testing a new glib2.0) and > https://ci.debian.net/packages/c/clevis/testing/amd64/46260455/ > (while testing a new glibc). Unfortunately, these log files are no longer available. Do you have an indicationing which test is failing? I guess it's not a particular one. However, I was able to produce a similar pattern, and I guess it's the same story: | I: Running test pin-tang | 2024/11/05 17:55:00 socat[184783] E bind(6, {AF=2 0.0.0.0:8888}, 16): Address already in use > I suspect this is a race condition in the test (perhaps starting a new > server before the previous server has been cleaned up?) rather than > genuinely being a regression in glib2.0 or glibc. Looking at the code, I fear it's worse: The port to bind to is chosen randomly, and that might either hit an existing port, or one used a few seconds earlier. Do you have an indication how often this autopkgtest failure happens? A listening socket is openend 22 times during the test, out of 64512 possible port numbers. If my birthday paradoxon calculations are correct, a collision has a likelyhood of roughly 0.3 percent. So I'm not certain whether I'm looking into the right corner, and therefore I'm a bit reluctant to implement a workaround. Christoph
signature.asc
Description: PGP signature
