From owner-freebsd-current@FreeBSD.ORG Fri Jun 25 14:04:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2B6E16A4CE for ; Fri, 25 Jun 2004 14:04:05 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BD0643D3F for ; Fri, 25 Jun 2004 14:04:05 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5PE3wGX037516; Fri, 25 Jun 2004 10:03:59 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5PE3wNS037513; Fri, 25 Jun 2004 10:03:58 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 25 Jun 2004 10:03:58 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Conrad J. Sabatier" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: fetch hangs on 6/24/04 current build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jun 2004 14:04:05 -0000 On Fri, 25 Jun 2004, Conrad J. Sabatier wrote: > I tried switching to wget, using "FETCH_CMD=wget -v -c" in > /etc/make.conf, and got the most bizarre behavior, something I've never > seen before. wget would fail each time, complaining about "invalid > option --". Very strange. It might be interesting to look at the following: - Use sockstat/netstat to identify the fetch socket, and see whether either the send of the receive queue contains some amount of persistent, un-processed data. This would suggest if the application was stalling and not reading, or that TCP was stalling and not sending. - Use DDB to generate a stack trace of the fetch process in-kernel, perhaps a few to see whether it's stuck in one place, and if so, where. This would tell us what it's stuck doing. - Use ktrace to generate a trace of fetch and "see what it's doing" when it appears to hang -- is it looping waiting for I/O, just blocked in kernel, etc. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research