Date: Mon, 16 Aug 2010 20:20:31 -0400 From: jhell <jhell@dataix.net> To: David Wolfskill <david@catwhisker.org> Cc: freebsd-ports@freebsd.org Subject: Re: It's annoying when something other than rsyncd listens on tco/873 Message-ID: <4C69D5CF.5050602@dataix.net> In-Reply-To: <20100816054932.GD1553@albert.catwhisker.org> References: <20100816054932.GD1553@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C69D5CF.5050602>