Hello again! Ludovic Courtès <[email protected]> skribis:
> Back in 2015, I closed <https://issues.guix.gnu.org/issue/20145> saying: > >> [email protected] (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’.
