Hi, And sorry for failing to produce a reply earlier :-).
zimoun <zimon.touto...@gmail.com> writes: [...] >>> From: Maxim Cournoyer <maxim.courno...@gmail.com> >>> Date: Fri, 18 Dec 2020 22:04:04 -0500 (24 weeks, 4 days, 18 hours ago) >>> >>> I'm not sure if the recent offloading work that Mathieu did touched that >>> topic. I'd need to test the scenario. Perhaps a system test would be >>> useful. >>> ---------- >>> >>> From: Ludovic Courtès <l...@gnu.org> >>> Date: Tue, 22 Dec 2020 16:16:08 +0100 >>> Date: Tue, 22 Dec 2020 16:16:08 +0100 (24 weeks, 1 day, 6 hours ago) >>> >>> Is it still a problem? Commit 4f5234be0378368e6af25925db46612838d25e58 >>> (Nov. 2019) added a table of unreachable hosts. That way, a ‘guix >>> substitute --query’ process won’t retry connections to an unreachable >>> host. >>> ---------- >>> >>> From: Efraim Flashner <efr...@flashner.co.il> >>> Date: Mon, 28 Dec 2020 14:19:02 +0200 >>> Date: Mon, 28 Dec 2020 14:19:02 +0200 (23 weeks, 2 days, 9 hours ago) >>> >>> Occasionally my internet drops itself, and I find I'm left forever >>> waiting for a timeout to see what sources I have cached locally. >>> ---------- >> >> What is the current stats of this bug? Is it still happening with the >> recent improvements of Cuirass? > > After reading all this, I think this bug can be closed. WDYT? Were you able to replay a scenario in which a substitute server is made unreachable? That's the information that I'd like to have/see before closing. I don't come across unreachable substitute servers often, and can't think of a way to easily test this. I could make it hang by dropping the input/output connections with iptables to a remote guix publish server, but then SSH also hangs, so perhaps that's expected. I'll try to configure a couple local machines to act as publish servers, and disconnect them from the network to see what happens. Thanks, Maxim
