Bug#821233: perlbal: FTBFS: Unable to start socket: Address already in use

Niko Tyni ntyni at debian.org
Thu Apr 21 20:55:57 UTC 2016


Control: reopen -1
Control: severity -1 important

On Sun, Apr 17, 2016 at 12:41:15AM +0200, gregor herrmann wrote:
> Control: tag -1 + unreproducible
> 
> On Sat, 16 Apr 2016 23:23:50 +0100, Chris Lamb wrote:
> 
> > perlbal fails to build from source in unstable/amd64:
> 
> >   Didn't get 200 OK: GET /reqdecr,status HTTP/1.0
> >   Unable to start socket: Address already in use
> >   # Looks like your test exited with 29 before it could output anything.
> >   t/32-selector.t .......... 
> >   1..38
> >   Dubious, test returned 29 (wstat 7424, 0x1d00)
> >   Failed 38/38 subtests 
> 
> The tests pass for me, both during build and in autopkgtest.

It has just failed on ci.debian.net in the same way for the first time
in a year or so.

I can (eventually) reproduce it locally by running t/32-selector.t in
a loop.  Caught it with strace, and it looks like

- the main process checks that the local port (in my case 60070) is free
  in Perlbal::Test::test_port() by making a new socket there and closing
  it immediately
- later, in Perlbal::Test::WebServer::start_webserver() a server child
  process is forked off and then the main process
  tries to connect it. It gets a connection on something which doesn't
  respond properly but rather echoes the request back
- in parallel but a bit later, the child process starts a server but gets
  EADDRINUSE from bind(2).

I'm not aware of having any other process running that's greedy for
local ports, and it seems really improbable that something would hit
by chance in the window between the first check and the actual use.

I wonder if the kernel is just slow to actually release the port after
the first check. But surely at least the connect(2) call should have
failed when the port was already closed. And why does the peer look
like an echo service?

I'm reopening but downgrading this. Perhaps we should just have
start_webserver() retry a couple of times somehow if it fails the
first time.
-- 
Niko Tyni   ntyni at debian.org



More information about the pkg-perl-maintainers mailing list