--- Begin Message ---
|
Subject: |
(guix build download) leaks file descriptor on TLS connections |
|
Date: |
Thu, 19 Mar 2015 19:16:24 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) |
When opening an HTTPS connection, the file descriptor beneath the port
returned by ‘tls-wrap’ is leaked.
This is not a problem in most cases (downloads) because the process is
left as soon as the download is over.
This is more problematic for ‘guix lint’, which may open a large number
of HTTPS connections for the ‘source’ and ‘home-page’ checkers when
working on all the packages.
Ludo’.
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#20145: (guix build download) leaks file descriptor on TLS connections |
|
Date: |
Fri, 03 Jan 2020 16:12:11 +0100 |
|
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) |
Hello again!
Ludovic Courtès <address@hidden> skribis:
> Back in 2015, I closed <https://issues.guix.gnu.org/issue/20145> saying:
>
>> address@hidden (Ludovic Courtès) skribis:
>>
>>> When opening an HTTPS connection, the file descriptor beneath the port
>>> returned by ‘tls-wrap’ is leaked.
>>>
>>> This is not a problem in most cases (downloads) because the process is
>>> left as soon as the download is over.
>>>
>>> This is more problematic for ‘guix lint’, which may open a large number
>>> of HTTPS connections for the ‘source’ and ‘home-page’ checkers when
>>> working on all the packages.
>>
>> This is essentially solved by commits
>> 14d6ca3e4dd23ee92adb5e2fcf58546e67534631 and
>> 097a951e96718a037dbfa6d579e2d26f7dab3e82.
>>
>> One still needs to be careful, though, for instance because closing a
>> chunked encoding port (which is a custom binary input port wrapped
>> around the real socket port) still fails to close the raw socket port
>> that’s behind the TLS session record port.
>
> Unfortunately, the bug just reported by Valentin and by Ricardo are
> instances of this problem (at least I checked with crates.io and it
> uses chunked encoding, leading to a file descriptor leak):
>
> https://issues.guix.gnu.org/issue/38857
> https://issues.guix.gnu.org/issue/38836
Commit f4cde9ac4aedb516c050a30fd999673da434bfa0 fixes it for good it
seems! (You can monitor /proc/PID/fd while ‘guix refresh’ or ‘guix
import crate -r’ is running. :-))
There was also a CRAN-specific FD leak fixed in
af0aefd8c10701fa32341506e36297e5105f6143.
Let me know is anything is amiss!
Ludo’.
--- End Message ---