I think we can do better for this use case (I believe what you describe might still happen in a modern libcurl version).

Let me just mention that libcurl cannot decide to deliberately do a "clean" or a "not clean" close, it simply closes the socket and sending a FIN or RST is something that the TCP/IP stack in the kernel decides on. Not libcurl.

Let me just mention that libcurl cannot decide to deliberately do a "clean" or a "not clean" close

I dont think thats completely true. It's been a while since I last did raw sockets, but if my memory serves me right you are supposed to invoke shutdown() on the socket to signal to the kernel that you want to close the connection. This will cause the kernel to send a FIN packet to the remote host which in turn flushes its buffers and sends a FIN as well. close immediately closes the socket and if the kernel does this closing dance its more a happy coincidence than guaranteed. You can read more about that here.

However in most cases the unclean shutdown isn't really an issue cause if you close the socket you probably dont care about data in the remotes buffers anyway. The bigger issue is that you can't tell libcurl to immediately close the connection without resorting to ugly hacks. In the ideal case multi would behave the same as easy except async.

Thanks for educating me on TCP, but this is not a problem of using or not using shutdown.

Do you happen to have a (small) example code that reproduces this issue?

Thanks for educating me on TCP, but this is not a problem of using or not using shutdown.

I by no means wanted to overbearing, but I have experienced that most people dont care what happens on the lower layers.

Do you happen to have a (small) example code that reproduces this issue?

Of course, I wrote a small one up. It uses the tcpbin.com echo service, but its not really important whats the target server, as long as it accepts tcp connections and doesn't immediately close them. You can toggle USE_MULTI to trigger the issue. With multi handles disabled everything works fine and the lsofcommand reports no active connections. With multi handles enabled the connection is not closed by the curl_easy_cleanup() call but lives on until the multi handle gets cleaned.

#include <curl/curl.h>  // For curl*
#include <stdio.h>      // For sprintf, printf
#include <stdlib.h>     // For system()
#include <unistd.h>     // For getpid()

#define USE_MULTI 1

int main() {
  CURL* hdl = curl_easy_init();
  curl_easy_setopt(hdl, CURLOPT_VERBOSE, (long)1);
  curl_easy_setopt(hdl, CURLOPT_CONNECT_ONLY, (long)1);
  curl_easy_setopt(hdl, CURLOPT_URL, "http://tcpbin.com:4242");

#if USE_MULTI
  CURLM* multi = curl_multi_init();
  curl_multi_add_handle(multi, hdl);

  CURLMsg* msg=NULL;
  int num= 0;
  while(!(msg = curl_multi_info_read(multi, &num)) || msg->msg != CURLMSG_DONE) {
      curl_multi_perform(multi, &num);
      curl_multi_wait(multi, NULL, 0, 100, NULL);
  }
  if(msg->data.result == CURLE_OK)
      printf("Connected\n");
  
  curl_multi_remove_handle(multi, hdl);
#else
  if(curl_easy_perform(hdl) == CURLE_OK)
      printf("Connected\n");
#endif

  // Connection should get closed here, but it isn't
  curl_easy_cleanup(hdl);

  // List active connections, will contain a handle
  char cmd_list_conns[128];
  sprintf(cmd_list_conns, "lsof -ai -p %d", (int)getpid());
  system(cmd_list_conns);

#if USE_MULTI
  // Even keeping the multi driven doesnt change anything
  for(int i =0; i<10; i++) {
      curl_multi_perform(multi, &num);
      curl_multi_wait(multi, NULL, 0, 100, NULL);
  }

  // Connection is still active here
  system(cmd_list_conns);

  // Connection only closed after the multi handle is cleaned
  curl_multi_cleanup(multi);
#endif
}

Thanks for the reproducer, it helped me work on this!

This behavior/bug happens because when we remove the easy handle from the multi handle, the association between the easy handle and the connection is cut and the connection is left in the connection cache (marked as cannot-be-reused). The connection cache is held in the multi handle.

When curl_easy_cleanup() is then called, it has no connection to close. It doesn't even know in which multi handle it was once added because it is blanked (and in fact the multi handle could be gone completely). The cleanup function cannot close the connection.

The fix is probably to make curl_multi_remove_handle() close the connection if CONNECT_ONLY was set, as there is no way to reach/use that connection again after the function is called.

PR pending.

#9342 fixes the problem in my tests