[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#38836: closed (guix refresh: Too many open files)

From: GNU bug Tracking System
Subject: bug#38836: closed (guix refresh: Too many open files)
Date: Fri, 03 Jan 2020 15:13:02 +0000

Your message dated Fri, 03 Jan 2020 16:12:11 +0100
with message-id <address@hidden>
and subject line Re: bug#20145: (guix build download) leaks file descriptor on 
TLS connections
has caused the debbugs.gnu.org bug report #20145,
regarding guix refresh: Too many open files
to be marked as done.

(If you believe you have received this mail in error, please contact

20145: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20145
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: guix refresh: Too many open files Date: Tue, 31 Dec 2019 20:50:55 +0100 User-agent: mu4e 1.2.0; emacs 26.3
I regularly run this command:

    ./pre-inst-env guix refresh -t cran,bioconductor -u

This makes a lot of HTTP requests to check for updates.  It often aborts
with this error before it can finish checking for updates of all

   guix refresh: error: open-file: Too many open files:


--- 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

Let me know is anything is amiss!


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]