IndexError raising CannotBindAddress error starting bzr serve

I should mention that I tried different --port arguments etc just to make sure. All no joy. We were forced to downgrade back to bzr 1.7.1

AfC

I think the underlying problem is that (as the traceback suggests) it cannot bind the listening socket. Could it be that 'bzr serve' or something else is already using port 4155 on this machine?

In both 1.8 and trunk I can run 'bzr serve' and get a reasonable error if it fails to bind the address because it's in use.

However, the CannotBindAddress constructor does seem strange to be indexing the original error this way. I'm not sure why this needs to be a special error class.

Uh no, nothing is already 4155. But more to the point, since the same thing happened when I tried it with $random other ports, I'm not really sure why CannotBindAddress is occurring. My guess is that that in turn is proxy for some other problem, but I wouldn't have the faintest idea where to even begin looking to articulate that.

AfC

Something a bit funny is going on indeed. On my Ubuntu intrepid laptop doing "bzr serve" in two terminals triggers a normal error, not a traceback:

$ bzr serve
bzr: ERROR: Cannot bind address "None:4155": Address already in use.

My guess is that the socket error that is triggering the error is not an "Address already in use" error, although what else it might be I don't know. What happens if you replace the "raise errors.CannotBindAddress(...)" line with a plain "raise"? (i.e. reraise the original exception)

Ah, the main change to this code since 1.7 is that it attempts to listen on IPv6 if possible, as well as IPv4.

The relevant patch hunk is:

@@ -59,13 +62,18 @@
         from socket import error as socket_error
         self._socket_error = socket_error
         self._socket_timeout = socket_timeout
- self._server_socket = socket.socket()
+ addrs = socket.getaddrinfo(host, port, socket.AF_UNSPEC,
+ socket.SOCK_STREAM, 0, socket.AI_PASSIVE)[0]
+
+ (family, socktype, proto, canonname, sockaddr) = addrs
+
+ self._server_socket = socket.socket(family, socktype, proto)
         # SO_REUSERADDR has a different meaning on Windows
         if sys.platform != 'win32':
             self._server_socket.setsockopt(socket.SOL_SOCKET,
                 socket.SO_REUSEADDR, 1)
         try:
- self._server_socket.bind((host, port))
+ self._server_socket.bind(sockaddr)
         except self._socket_error, message:
             raise errors.CannotBindAddress(host, port, message)
         self._sockname = self._server_socket.getsockname()

So I guess attempting to bind to an IPv6 port is raising an unexpected sort of socket error on your system?

If you can tell us which exception is being raised, we can probably fix this to just fall back to the IPv4-only code when it occurs.

On Tue, Oct 21, 2008 at 10:01 PM, Andrew Bennetts
<email address hidden> wrote:
> Ah, the main change to this code since 1.7 is that it attempts to listen
> on IPv6 if possible, as well as IPv4.

Yes, you can get things like this on machines that eg know about ipv6
but don't have any ipv6 addresses. I think distcc has something to
work around this.

If I'd reviewed that change I think I would have suggested listening
only on ipv4 by default unless the user specifically asked for it with
--port, as for most users today it will only cause trouble.

--
Martin <http://launchpad.net/~mbp/>

If my theory is true, Andrew may be able to work around the problem by
using --port to explicitly give an ipv4 host address, eg

  --port 127.0.0.1:12345

I'll try the workaround presently, but off hand I can tell you that the services on that server are only set to listen on normal IP addresses. We don't waste time with IPv6 stuff.

AfC

Yes, specifying

--port 0.0.0.0:4155

allowed it to work.

AfC

On Wed, Oct 22, 2008 at 1:17 PM, Andrew Cowie
<email address hidden> wrote:
> I'll try the workaround presently, but off hand I can tell you that the
> services on that server are only set to listen on normal IP addresses.
> We don't waste time with IPv6 stuff.

OK, thanks for confirming that.

--
Martin <http://launchpad.net/~mbp/>

We should be specifying AI_ADDRCONFIG - that way getaddrinfo() only returns addresses that can actually be used. Unfortunately, this doesn't appear to exist on Windows.

Re-open if I'm wrong but this has been fixed in 2.0rc1