Haxx ad

curl's project page on


cURL > Mailing List > Monthly Index > Single Mail

curl-tracker Archives

[ curl-Bugs-3297118 ] some sockets hang in CLOSE_WAIT forever?

From: <>
Date: Thu, 12 May 2011 23:59:34 +0200

Bugs item #3297118, was opened at 2011-05-03 23:31
Message generated for change (Comment added) made by bagder
You can respond by visiting:

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: libcurl
Group: bad behaviour
>Status: Pending
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Charles Kerr ()
Assigned to: Daniel Stenberg (bagder)
Summary: some sockets hang in CLOSE_WAIT forever?

Initial Comment:
I'm one of the developers on Transmission, which uses libcurl. A user is reporting that in some cases -- apparently those involving an http redirect -- that Transmission + libcurl is leaving sockets in CLOSE_WAIT indefinitely. This user is on OS X 10.6.6, which appears to be shipping with libcurl 7.19.7.

I haven't seen this issue myself, but I'm not running OS X. So I don't know if this is (a) an issue with libcurl, or (b) an issue with how Transmission is using libcurl, or (c) a phantom issue.

(b) seems the most likely, since there are more eyes on libcurl than on Transmission... but its use of libcurl is trivially straightforward. Does this look correct:

    multi = curl_multi_init( );
         // add tasks to curl
        curl_multi_add_handle( multi, createEasy( session, web, task ));

        // possibly wait a bit via curl_multi_timeout() + curl_multi_fdset() + select()

        // perform
        do {
            mcode = curl_multi_perform( multi, &unused );
        } while( mcode == CURLM_CALL_MULTI_PERFORM );

        // pump completed tasks from the multi
        while(( msg = curl_multi_info_read( multi, &unused ))) {
            if(( msg->msg == CURLMSG_DONE ) && ( msg->easy_handle != NULL )) {
                CURL * e = msg->easy_handle;
                // (libtransmission-centric steps omitted here)
                curl_multi_remove_handle( multi, e );
                curl_easy_cleanup( e );
    while( tasks_remain || app_is_shutting_down ); // pseudocode

Does this look correct to you?

One option suggested is to try CURLOPT_FORBID_REUSE, but that seems like a blunt tool for this case. If Transmission or libcurl really are leaking sockets, it would be better to find out why than to disable reuse.

Thanks for your time. If you have any questions please ask.


Comment By: Daniel Stenberg (bagder)
Date: 2011-05-12 23:59

Thanks for reporting this issue and helping us improve curl and libcurl.

We're awaiting feedback in this issue. Due to this, I have set the state
of this issue to pending and it will automatically get closed later on
unless we get further info.

Please consider answering the outstanding questions or providing the
missing info so that we can proceed to resolve this issue!


Comment By: Daniel Stenberg (bagder)
Date: 2011-05-04 19:42

The CLOSE_WAIT sockets are probably the ones that libcurl has in its
connection cache but that have been "closed" (a FIN was sent) by the server
already but not yet by libcurl.

They are not there "indefinitely" (and they really can't be) since the
connection cache has a limited size so eventually the old connections
should get closed. Also, for each newly created connection when searching
if there's an existing one, libcurl is supposed to detect and close "dead"
connections such as these. Possibly that detection is somehow not working
on Mac OS X.

Your code looks correct and quite frankly, I don't think you describe a
bug but mere symptoms of how libcurl works.


You can respond by visiting:
Received on 2011-05-12

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET