From owner-freebsd-stable@FreeBSD.ORG Sun Mar 13 17:46:14 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9903E1065673 for ; Sun, 13 Mar 2011 17:46:14 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from doug-optiplex.ka9q.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id C0D12178BFA; Sun, 13 Mar 2011 17:45:12 +0000 (UTC) Message-ID: <4D7D02A8.30001@FreeBSD.org> Date: Sun, 13 Mar 2011 10:45:12 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110304 Thunderbird/3.1.9 MIME-Version: 1.0 To: Daniel Braniss References: <2122282816.1268010.1299884622480.JavaMail.root@erie.cs.uoguelph.ca> <4D7BEF8F.9080604@dougbarton.us> In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Rick Macklem , freebsd-stable@freebsd.org Subject: Re: statd/lockd startup failure X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 17:46:14 -0000 On 03/13/2011 08:23, Daniel Braniss wrote: >> On 03/12/2011 02:21, Daniel Braniss wrote: >>> The problem with trying to get the same port for all tcp/udp/inet/inet6 >>> though might succeed most of the time, will fail sometimes, then what? >> >> Can you please describe the scenario when it's completely impossible to >> find a port that's open on all 4 families? > i did not say impossible, concidering that Rick asked how many times he > should try, unless N is forever, it could fail. And what I'm asking is that you describe the circumstances which might lead to that failure. >>> I saw Doug's commnent, and also the:), it's not as simple as tracking port >>> 80 or 25, needs some efford, but it's deterministic/programable, and worst case >>> you can still use the -p option (which again will fail sometimes:-). >> >> Given that Rick has already written the patch, I don't think it's at all >> unreasonable to put it in as the first choice, perhaps with a fallback >> to picking any available port if there isn't one available for all 4 >> families. >> > as Rick mentioned, the patch is not trivial, and to quote him: > "My only concern with the "same port# patch" is that it is more complex > and, therefore, somewhat riskier w.r.t. my having gotten it wrong." Yeah, I saw that, did you see my response? I'm very much in favor of keeping things simple, but only as simple as they can be made. >> Meanwhile, I don't think I'm the only person who has ever had trouble >> trying to track down network traffic from "random" ports that would >> prefer that doing so not be made harder by having the same service on >> the same host using 4 different ports. > > To track rpc based traffic, which means random-port to start with, you have to > check with rpcinfo anyways. So yes, it's harder than tracking 1 port, but > IMHO, less complex than the patch requiered :-), Clearly you've not spent any significant amount of time trying to figure out what traffic is coming from what port. A small increase in code complexity is worth it if it saves real people real time, especially in critical situations. > and BTW, mountd is already > heavely patched, rpc.statd less, and rpc.lockd is, so far, the only one > that is not complaining - guess Rick is a good programer! > > and I concider myself lucky that we don't use NIS/yellow-pages. Some of us are not so lucky. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/