From owner-freebsd-ports@FreeBSD.ORG Tue Aug 17 00:20:36 2010 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDC45106566C for ; Tue, 17 Aug 2010 00:20:36 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EF6E8FC0C for ; Tue, 17 Aug 2010 00:20:35 +0000 (UTC) Received: by ywk9 with SMTP id 9so2671150ywk.13 for ; Mon, 16 Aug 2010 17:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ky95oZRg2kCfiPhj51w5KyUp+yl0oPNK/IZYbZ5oo0g=; b=GZTSrEgZty5wvXaqx+79omS1Dd6nzKzeI9foRp7rt0/TZl4Dl1CgHoGjKF4hMfm1c6 xoRcdXu0DTRYvkkjMQPT3wFMevRfcYjBVhcbtaK8Ev2qPFhz/wJu6uqX83DVMPlAa6iO KaJz/6DUr/c5AUMwBSNSVOBUCtfYEqwkfViZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=pzGWc4uo5ryQNX3NhByftvUKNM5C/2rhFqF2I2o8OVQsTD5/WaAvn9dalQT8Syfwch 9j0CbPQWOw8jSd5NkEiOrjh1u4+wFlXZeW//BwpmPyYrXNTp31lhXt6Bc5NDXwjStLXi ukABTq/lcSa/KwXTmwajMEib9aJ0PFIiDlGXY= Received: by 10.100.124.1 with SMTP id w1mr6566744anc.265.1282004434991; Mon, 16 Aug 2010 17:20:34 -0700 (PDT) Received: from centel.dataix.local (adsl-99-190-82-4.dsl.klmzmi.sbcglobal.net [99.190.82.4]) by mx.google.com with ESMTPS id w6sm11194596anb.3.2010.08.16.17.20.33 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Aug 2010 17:20:34 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4C69D5CF.5050602@dataix.net> Date: Mon, 16 Aug 2010 20:20:31 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100806 Lightning/1.0b1 Thunderbird MIME-Version: 1.0 To: David Wolfskill References: <20100816054932.GD1553@albert.catwhisker.org> In-Reply-To: <20100816054932.GD1553@albert.catwhisker.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-ports@freebsd.org Subject: Re: It's annoying when something other than rsyncd listens on tco/873 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 00:20:36 -0000 On 08/16/2010 01:49, David Wolfskill wrote: > My build machine is noisy & generates heat, so I leave it powered off > when it's not actively in use. > > As a consequence, it gets rebooted rather often. > > It is configured to run rsyncd(8) so I can update my laptop's local mirror > of the FreeBSD SVN repository. > > A couple of mornings ago, I woke up, ready to start my daily builds (on > the laptop & build machine), but noticed that the SVN mirror on the > laptop hadn't been updated. Eventually, I discovered that the reason > was that amd(8) [on the build machine] was listening on 873/tcp, which > is the port for rsync. I restarted amd(8); it happened to get other > ports, so I restarted rsyncd(8), and was able to perfomr the mirroring. > > Mind, that was the first time since around February that I've had a > problem with using rsyncd(8) in this fashion. > > Since then, I've become a bit ... sensitized .... to the issue, so a > quick "sockstat -4l" immediately after powering it on helps avoid ths > sort of thing. > > So this evening, such a check showed that ypbind(8) was listening on > 873/tcp. > > The most straightforward way to make this a non-issue (it seems to me) > would be to start rsyncd(8) before other services that grab arbitrary > ports; however, the start-up script for rsyncd s[ecifies: > > # PROVIDE: rsyncd > # REQUIRE: LOGIN > # BEFORE: securelevel > # KEYWORD: shutdown > > and both amd & ypbind specify > > # BEFORE: DAEMON > > so that approach doesn't seem to quite work out. > > (I note that I recently stopped tracking stable/7 on the build machine, > so I now boot into stable/8; perhaps something changed between stable/7 > and stable/8 that inicreases the probability of such an unfortunate > collsion.) > > Also, rsyncd(8) doesn't appear to consider this a condition worthy of > note -- at least, I wasn't able to find any whines, and the daemon was > still running. > > Anyone have suggestions for avoiding a recurrence (vs. working around > the coiindition should one occur)? > I have been at this point once or twice and it always boiled down to rpcbind in my situation on a few NIS+ boxen. The problem that I came across was that /usr/local/etc/rc.d is parsed long after /etc/rc.d contents so adding the BEFORE to the rsync start script would not help or didn't at that time. One thing that comes to mind is that script that Jeremy? posted for waiting for the network a certain period of time before initializing services. Maybe this could also play a role in a situation to have a services script that could be controlled by rc.conf(5) to wait for a service to come up before continuing its own operation. And of course it should continue no matter what in either case but would allow you to introduce possibly needed delays in the rc. Here is a slightly modified version of Jeremy's script that I use. http://bit.ly/cpbrlm Food-4-Thought Regards, -- jhell,v