socket.error: [Errno 98] Address already in use

[cerr]

Hi There,

I get a socket error "[Errno 98] Address already in use" when i try to
open a socket that got closed before with close(). How come close()
doesn't close the socket properly?
My socket code :

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((host, port))
s.listen(1)
....
....
....
while loop:
conn, addr = s.accept()
while conn and loop:
....
....
....
conn.close()

Shouldn't that clean it all up properly?

Thanks for hints & suggestions!
Ron

 

[Thomas Jollans]

Hi There,

I get a socket error "[Errno 98] Address already in use" when i try to
open a socket that got closed before with close(). How come close()
doesn't close the socket properly?
My socket code :

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((host, port))
s.listen(1)
...
...
...
while loop:
conn, addr = s.accept()
while conn and loop:
...
...
...
conn.close()

Shouldn't that clean it all up properly?

`s` is still listening?

 

[jipalaciosortega]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 15/09/2010 20:58, Grant Edwards escribió:

I get a socket error "[Errno 98] Address already in use" when i
try to open a socket that got closed before with close(). How
come close() doesn't close the socket properly? My socket code :

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((host, port)) s.listen(1) ... ... ... while loop: conn,
addr = s.accept() while conn and loop: ... ... ... conn.close()

At what line does the error occur?

To what does the phrase "open a socket" refer?

Have you tried the usual solution of setting the SO_REUSEADDR
option on the socket before calling bind?

http://www.google.com/search?q=socket+'address+already+in+use'

Maybe, you have any other proccess in your system using your listen
port, for example apache...

- --
_ _ _ _ _ _ _ _ _ _ _
Jose Ignacio Palacios Ortega /_ _/ / / / _ / / _ /
Telf: +34 637 058 813 / / / / / /_ / / / / / /
Correo-e: (e-mail address removed) _ / / / / / _ _ _/ / / / /
Msn: (e-mail address removed) / /_ / / / / / / / /_/ /
ID firma PGP: 0x0EB87E48 \ _ _ / /_/ /_/ /_ _ _/
Huella PGP:61CC 5DA0 827B C3AB F83C 2A55 78AF B317 0EB8 7E48
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyRafgACgkQeK+zFw64fkjH2wCffe4v8ho2z4d8LWaPaiJRu0OZ
4cgAniOoR70hu7UylkpgAr3JI5hxNXYP
=MoYK
-----END PGP SIGNATURE-----

 

[cerr]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 15/09/2010 20:58, Grant Edwards escribió:

I get a socket error "[Errno 98] Address already in use" when i
try to open a socket that got closed before with close(). How
come close() doesn't close the socket properly? My socket code :
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((host, port)) s.listen(1) ... ... ... while loop: conn,
addr = s.accept() while conn and loop: ... ... ... conn.close()

At what line does the error occur?

To what does the phrase "open a socket" refer?

Have you tried the usual solution of setting the SO_REUSEADDR
option on the socket before calling bind?

http://www.google.com/search?q=socket+'address+already+in+use'

Maybe, you have any other proccess in your system using your listen
port, for example apache...

Nope negative, I have one process on my system only that occupies port
1514.

 

[cerr]

I get a socket error "[Errno 98] Address already in use" when i try to
open a socket that got closed before with close(). How come close()
doesn't close the socket properly?
My socket code :

  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
  s.bind((host, port))
  s.listen(1)
...
...
...
  while loop:
    conn, addr = s.accept()
    while conn and loop:
...
...
...
     conn.close()

At what line does the error occur?

The whole message I get looks like:
Traceback (most recent call last):
File "./checkGPIO.py", line 148, in <module>
main()
File "./checkGPIO.py", line 75, in main
s.bind((host, port))
File "<string>", line 1, in bind
socket.error: [Errno 98] Address already in use

Where line 75 contains following:
s.bind((host, port))

To what does the phrase "open a socket" refer?

create a listening socket...?

Have you tried the usual solution of setting the SO_REUSEADDR option
on the socket before calling bind?

yep, that did it for me, thanks a lot!

http://www.google.com/search?q=socket+'address+already+in+use'

Google's your friend if you can read

 

[björn lundin]

Where line 75 contains following:
s.bind((host, port))

As Tomas pointed out, you close conn, but you do not close the server
socket 's'

/Björn

 

[Lawrence D'Oliveiro]

In message

I get a socket error "[Errno 98] Address already in use" when i try to
open a socket that got closed before with close(). How come close()
doesn't close the socket properly?

The usual case this happens is you have a client connection open at the
time, that was not properly terminated. Then the TCP stack goes through a
holdoff period (2 minutes, I believe it is), to make absolutely sure all
packets destined for the old connection have completely disappeared off the
entire Internet, before it will let you open a socket on the same port
again.

 

[Grant Edwards]

In message

I get a socket error "[Errno 98] Address already in use" when i try to
open a socket that got closed before with close(). How come close()
doesn't close the socket properly?

The usual case this happens is you have a client connection open at the
time, that was not properly terminated. Then the TCP stack goes through a
holdoff period (2 minutes, I believe it is), to make absolutely sure all
packets destined for the old connection have completely disappeared off the
entire Internet, before it will let you open a socket on the same port
again.

Even when the connection was properly terminated (from an
application's POV), there's a TIME_WAIT period before the TCP stack
considered the connection completely gone and will allow re-use of the
port. IOW, the TIME_WAIT is actually part of the connection
termination (from the TCP stack's POV), and it can takes place after
the application considers the connection closed (and may have even
exited):

http://www.developerweb.net/forum/showthread.php?t=2941

 

[Lawrence D'Oliveiro]

Even when the connection was properly terminated (from an
application's POV), there's a TIME_WAIT period before the TCP stack
considered the connection completely gone and will allow re-use of the
port.

I’m not so sure about that. I’ve done a bunch of development on a system
recently which had a server process written in Python running on a Linux
box, accepting connections from a client running under old MacOS 9 (don’t
ask) which was, of course, prone to crash.

If the client had shut down cleanly, then I could stop and restart the
server process without any problems reopening the socket. But if I forgot to
close the client, then the server would hit the “already in use†error.

To deal with it, I simply put in an automatic retry at 60-second intervals
until it succeeded in reopening the socket.

 

[Jorgen Grahn]

In message

I get a socket error "[Errno 98] Address already in use" when i try to
open a socket that got closed before with close(). How come close()
doesn't close the socket properly?

The usual case this happens is you have a client connection open at the
time, that was not properly terminated. Then the TCP stack goes through a
holdoff period (2 minutes, I believe it is), to make absolutely sure all
packets destined for the old connection have completely disappeared off the
entire Internet, before it will let you open a socket on the same port
again.

That's why Stevens recommends that all TCP servers use the
SO_REUSEADDR socket option. He also noted in his book:

"This scenario is one of the most frequently asked
questions on Usenet."

Possibly I missed something in the question, but it's worth googling for.

/Jorgen

 

[Lawrence D'Oliveiro]

That's why Stevens recommends that all TCP servers use the
SO_REUSEADDR socket option.

I don’t think I’ve ever used that. It seems to defeat a safety mechanism
which was put in for a reason.

 

[Nobody]

I don’t think I’ve ever used that. It seems to defeat a safety mechanism
which was put in for a reason.

It was put in for the benefit of clients, to prevent them from selecting
a port which they won't be able to use. At the point that the program
calls bind(), the kernel doesn't know whether the program will call
connect() or listen() next (i.e. whether it's a client or a server).

Even if you set SO_REUSEADDR, you cannot create a connection which could
be confused with an existing connection, i.e. one with the same source and
destination address and port (BSD allows this provided that the previous
connection is closed and the initial sequence number of the new connection
exceeds the final sequence number of the previous connection).

For a client, re-using the port would mean that any attempt to connect to
the same port and address as an existing TIME_WAIT connection will fail
with EADDRINUSE, so it should choose another port. This scenario is quite
likely, as a client for a particular protocol will tend to connect to a
specific remote port, and often to a small set of servers.

But a server often has to use a specific port, and its clients will
typically connect from ephemeral ports. Even if some clients insist on
trying to use a specific source port (which will fail so long as the
TIME_WAIT connections exist), the server can still serve other clients.

 

[Lawrence D'Oliveiro]

It was put in for the benefit of clients, to prevent them from selecting
a port which they won't be able to use.

But clients typically don’t care what port they use—they let the system pick
a port for them, so this kind of option is unnecessary.

 

[Nobody]

But clients typically don’t care what port they use—they let the
system pick a port for them, so this kind of option is unnecessary.

If they use an ephemeral port, the kernel won't pick a port which has any
connections in the TIME_WAIT state.

However, some clients choose their own source ports. E.g. rlogin/rsh use
privileged (low-numbered) ports, and you can't get the kernel to choose a
random privileged port for you.

If you're writing a server which listens on a known port, you *should* be
using SO_REUSEADDR to avoid unnecessary delays in start-up. The kernel
will automatically reject packets relating to stale connections, and your
server should be accepting any new connections ASAP.

 

[Lawrence D'Oliveiro]

However, some clients choose their own source ports. E.g. rlogin/rsh use
privileged (low-numbered) ports, and you can't get the kernel to choose a
random privileged port for you.

But nobody uses rlogin/rsh any more, and who would attach any trustworthy
meaning to a connection coming from a remote low-numbered source port?

If you're writing a server which listens on a known port, you *should* be
using SO_REUSEADDR to avoid unnecessary delays in start-up. The kernel
will automatically reject packets relating to stale connections, and your
server should be accepting any new connections ASAP.

That makes it sound like SO_REUSEADDR should really be a superfluous option.
But it’s not.

 

[Nobody]

But nobody uses rlogin/rsh any more,

They did when the bind() and SO_REUSEADDR semantics were developed. If
they were doing it now, chances are that SO_REUSEADDR would be enabled by
default.

and who would attach any trustworthy
meaning to a connection coming from a remote low-numbered source port?

If you receive a connection with a low-numbered source port and it
*isn't* legitimate, then someone has got root (in which case any other
authentication mechanism isn't safe either) or someone has hijacked the
IP address (you do know that low-numbered ports are only meaningful for
systems under your control, right?).

Using a firewall rule which only allows connections from a low port on
specific IP addresses certainly isn't any worse than a rule which only
allows connections from any port on specific IP addresses. That's true
regardless of whether the protocol includes other authentication
mechanisms.

That makes it sound like SO_REUSEADDR should really be a superfluous option.
But it’s not.

Well it is mostly superfluous. It should always be enabled for a server
listening on a known port, and doesn't matter for a client which uses
ephemeral ports.