Date: Sat, 9 Dec 2006 20:49:24 -0500 From: Adam McDougall <mcdouga9@egr.msu.edu> To: Colin Percival <cperciva@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: Fwd: Re: pf: BAD state happens often with portsnap fetch update Message-ID: <20061210014924.GU81923@egr.msu.edu> In-Reply-To: <457B621E.3020100@freebsd.org> References: <20061210010823.GS81923@egr.msu.edu> <457B621E.3020100@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Dec 09, 2006 at 05:25:50PM -0800, Colin Percival wrote: Adam McDougall wrote: > # portsnap fetch update > [...] > Fetching 2688 new ports or files... /usr/sbin/portsnap: cannot open > 3f115cb168a8e51fd0d19798f005ab7a251a1de6a5b9eda60cd327b60aa48799.gz: No such file or > directory > snapshot is corrupt. > > 2597 should have been fetched, but there was a stall at 30.. and after about a minute, > it continued on to 410...... and gave up apparently. For all my servers without > direct internet access, I have to run portsnap several times until it succeeds. You have four options: (a) Lower pf's tcp.closed timeout, (b) Increase the high port range, (c) Fix squid so that it groks HTTP/1.1 properly, or (d) Stop using squid. The problem here is that your proxy is closing portsnap's HTTP connection after each file is downloaded. I just tested tcp.closed with 3 seconds, down from 15 earlier but both were unsuccessful. I will look at the other options as well, but do you have any explanation for why portsnap would use wildly randomish local ports that overlap too quickly when fetch does not? Is that a kernel controlled behavior that I can adjust? 65535-49152=16383 (unless I am looking at the wrong sysctl for the default values) and I would think there are many less connections involved for 2597 fetches than 16363. If 16363 isn't enough ports for 2597 fetches then it seems like a crapshoot to try doubling or tripling the range.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061210014924.GU81923>