It's annoying when something other than rsyncd listens on
pschmehl_lists at tx.rr.com
Tue Aug 17 15:18:09 UTC 2010
--On Monday, August 16, 2010 20:20:31 -0400 jhell <jhell at dataix.net> wrote:
> 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
>> 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
>> 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.
The IP_PORTRANGE value, which is used by ypbind and amd to select a port, is
adjustable according to your needs. man (4) ip
"IP_PORTRANGE_DEFAULT use the default range of values, normally
IPPORT_HIFIRSTAUTO through IPPORT_HILASTAUTO. This
is adjustable through the sysctl setting:
Note that the man page is incorrect for FreeBSD 8.
# uname -r
# sysctl net | grep portrange
So set net.inet.ip.portrange.lowlast to 874. That should keep rsyncd's port
from being grabbed, unless I'm misunderstanding this, in which case Matthew or
someone else will correct me.
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
More information about the freebsd-ports