It's annoying when something other than rsyncd listens on
jyoti.mickey at gmail.com
Mon Aug 16 11:02:32 UTC 2010
I would prefer this approach:
amd.conf has the option preferred_amq_port to specify the listening
port. Don't know about ypbind.
It is not just rsyncd that can get disturbed. Grabbing arbitrary port
without consulting /etc/services and the startup scripts is a bad idea
for any service.
bindresvport() is at the bottom of the problem and there seems to be
no readily available workaround.
There is a portreserve tool in debian to avoid such situation. Don't
know if we have an equivalent in FreeBSD.
On 16 August 2010 11:19, David Wolfskill <david at catwhisker.org> 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)?
> David H. Wolfskill david at catwhisker.org
> Depriving a girl or boy of an opportunity for education is evil.
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.
More information about the freebsd-ports