Date: Fri, 20 Feb 2026 18:02:38 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 293312] fetch fails to time out during either transfer or lookup (see 293124) Message-ID: <bug-293312-227-xdAYROY8pk@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-293312-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293312 Dag-Erling Smørgrav <des@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |des@FreeBSD.org CC| |des@FreeBSD.org Status|New |In Progress Flags| |mfc-stable15?, | |mfc-stable14?, | |mfc-stable13? --- Comment #1 from Dag-Erling Smørgrav <des@FreeBSD.org> --- I specifically asked for `kdump -E -tcst`, but ok, we can do without. The log shows that SIGINT is delivered while we are waiting for DNS resolution. The ktrace, however, shows that SIGINT is delivered after DNS resolution, while we are trying to connect to the server. So this is, at root, a network issue, compounded by two separate issues in libfetch: 1) When DNS returns multiple addresses and connect(2) is interrupted, fetch_connect() should return immediately instead of trying the next address. This is definitely a bug. 2) Libfetch does not attempt to enforce the timeout while connecting. This was an intentional omission, because it's a genuinely hard problem to solve. We should either fix it or document it. Additionally, the fetch(3) manual page does not document fetchTimeout, and the fetch(1) manual page does not specify what the timeout applies to. -- You are receiving this mail because: You are the assignee for the bug.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-293312-227-xdAYROY8pk>