[PR #739] [MERGED] cleanup curl handle state on retries #1622

New issue

Closed

opened 2026-03-04 02:01:22 +03:00 by kerem · 0 comments

kerem commented

2026-03-04 02:01:22 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/s3fs-fuse/s3fs-fuse/pull/739
Author: @orozery
Created: 3/29/2018
Status: ✅ Merged
Merged: 4/1/2018
Merged by: @ggtakec

Base: master ← Head: cleanup_failing_curl_handles

📝 Commits (1)

adcf575 cleanup failing curl handles on retries

📊 Changes

1 file changed (+8 additions, -1 deletions)

View changed files

📝 src/curl.cpp (+8 -1)

📄 Description

Details

I encountered this re-occurring issue, popping once every few days of running an s3fs mountpoint:
A curl request failed with a readwrite_timeout.
S3fs retries the request -> gets curl error 35 CURLE_SSL_CONNECT_ERROR.
The same request is retried again -> same error CURLE_SSL_CONNECT_ERROR.
While the retries of this request fail, other requests do complete successfully.
This lead me to think that the CURL handle of the retry connection is re-using state (specifically SSL state) from the old (failing) connection.
I made this PR to cleanup the SSL state (or any other state) of the retry handle, by creating a fresh handle, with curl caches disabled (only for the retry request).

I tested with this patch and found that the issue is resolved.
@ggtakec would appreciate your approval.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/s3fs-fuse/s3fs-fuse/pull/739 **Author:** [@orozery](https://github.com/orozery) **Created:** 3/29/2018 **Status:** ✅ Merged **Merged:** 4/1/2018 **Merged by:** [@ggtakec](https://github.com/ggtakec) **Base:** `master` ← **Head:** `cleanup_failing_curl_handles` --- ### 📝 Commits (1) - [`adcf575`](https://github.com/s3fs-fuse/s3fs-fuse/commit/adcf5754ae8de4dea0c10c327cda01b22f9ffc98) cleanup failing curl handles on retries ### 📊 Changes **1 file changed** (+8 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `src/curl.cpp` (+8 -1) </details> ### 📄 Description ### Details I encountered this re-occurring issue, popping once every few days of running an s3fs mountpoint: A curl request failed with a readwrite_timeout. S3fs retries the request -> gets curl error 35 CURLE_SSL_CONNECT_ERROR. The same request is retried again -> same error CURLE_SSL_CONNECT_ERROR. While the retries of this request fail, other requests do complete successfully. This lead me to think that the CURL handle of the retry connection is re-using state (specifically SSL state) from the old (failing) connection. I made this PR to cleanup the SSL state (or any other state) of the retry handle, by creating a fresh handle, with curl caches disabled (only for the retry request). I tested with this patch and found that the issue is resolved. @ggtakec would appreciate your approval. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>