From owner-freebsd-stable@FreeBSD.ORG Sun Feb 20 18:16:45 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A752A1065670 for ; Sun, 20 Feb 2011 18:16:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 682428FC18 for ; Sun, 20 Feb 2011 18:16:45 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAC7pYE2DaFvO/2dsb2JhbACEIKMFqXuPR4Eng0F2BIUNhwY X-IronPort-AV: E=Sophos;i="4.62,195,1297054800"; d="scan'208";a="110489918" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 20 Feb 2011 13:16:44 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 990C4B3FB5; Sun, 20 Feb 2011 13:16:44 -0500 (EST) Date: Sun, 20 Feb 2011 13:16:44 -0500 (EST) From: Rick Macklem To: Doug Barton Message-ID: <366211571.149783.1298225804605.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <4D6061B9.4030706@dougbarton.us> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2692) Cc: mike@jellydonut.org, george+freebsd@m5p.com, freebsd-stable@freebsd.org, Jeremy Chadwick 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, 20 Feb 2011 18:16:45 -0000 > On 02/19/2011 13:16, Rick Macklem wrote: > >> On 02/18/2011 10:08, Rick Macklem wrote: > >>> The attached patches changes the behaviour so that it tries to > >>> get an unused port for each of the 4 cases. > >> > >> Am I correct in assuming that what you're proposing is to > >> (potentially) > >> have different ports for all 4 combinations? I would suggest that > >> this > >> is not the right way to solve the problem. If I misunderstand, I > >> apologize. > >> > > Well, that was what I was proposing. > > I think that would be a bad idea. It's hard enough to deal with > tracking > these services when they are on the same port. :) > > I don't think there is a single function that you can call that will > provide you an open port on all 4, although it would probably be nice > if > we had one. Something along the line of open a port for 1, then try to > open the same port on the other 3. If one of them fails, start the > process over. In the common case (starting the services when the > system > starts) it shouldn't be difficult to find a port that is open on all > 4. > Yea, it would be a much bigger patch, but should be doable. I don't know about "tracking" (whatever that means?), but I can see the argument for doing this so that the # of ports used is minimized. I'll wait to see if the patch fixes the problem before I proceed. Btw, one issue w.r.t. the above algorithm is "how many iterations do you do before giving up, when it fails?". I'd say "forever", but logging something every 10 attempts, since the likelyhood of N failures before a success only decreases, but never hits 0. rick