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

Discussion in 'Python' started by cerr, Sep 15, 2010.

  1. cerr

    cerr Guest

    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))
    while loop:
    conn, addr = s.accept()
    while conn and loop:

    Shouldn't that clean it all up properly?

    Thanks for hints & suggestions!
    cerr, Sep 15, 2010
    1. Advertisements

  2. `s` is still listening?
    Thomas Jollans, Sep 15, 2010
    1. Advertisements

  3. cerr


    Hash: SHA1

    El 15/09/2010 20:58, Grant Edwards escribió:
    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: _ / / / / / _ _ _/ / / / /
    Msn: / /_ / / / / / / / /_/ /
    ID firma PGP: 0x0EB87E48 \ _ _ / /_/ /_/ /_ _ _/
    Huella PGP:61CC 5DA0 827B C3AB F83C 2A55 78AF B317 0EB8 7E48
    Version: GnuPG v1.4.10 (MingW32)
    Comment: Using GnuPG with Mozilla -

    -----END PGP SIGNATURE-----
    , Sep 16, 2010
  4. cerr

    cerr Guest

    Nope negative, I have one process on my system only that occupies port
    cerr, Sep 16, 2010
  5. cerr

    cerr Guest

    The whole message I get looks like:
    Traceback (most recent call last):
    File "./", line 148, in <module>
    File "./", 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))
    create a listening socket...?
    yep, that did it for me, thanks a lot! :)
    Google's your friend if you can read ;)
    cerr, Sep 16, 2010
  6. As Tomas pointed out, you close conn, but you do not close the server
    socket 's'

    björn lundin, Sep 16, 2010
  7. In message
    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
    Lawrence D'Oliveiro, Sep 18, 2010
  8. 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
    Grant Edwards, Sep 18, 2010
  9. 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.
    Lawrence D'Oliveiro, Sep 18, 2010
  10. cerr

    Jorgen Grahn Guest

    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 Grahn, Sep 19, 2010
  11. I don’t think I’ve ever used that. It seems to defeat a safety mechanism
    which was put in for a reason.
    Lawrence D'Oliveiro, Sep 19, 2010
  12. cerr

    Nobody Guest

    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.
    Nobody, Sep 19, 2010
  13. 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.
    Lawrence D'Oliveiro, Sep 19, 2010
  14. cerr

    Nobody Guest

    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.
    Nobody, Sep 19, 2010
  15. 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?
    That makes it sound like SO_REUSEADDR should really be a superfluous option.
    But it’s not.
    Lawrence D'Oliveiro, Sep 20, 2010
  16. cerr

    Nobody Guest

    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
    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
    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.
    Nobody, Sep 21, 2010
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.