It's annoying when something other than rsyncd listens on tco/873

[Jyoti Sharma]

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.

Regards,
Jyoti


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
> 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)?
>
> Thanks!
>
> Peace,
> david
> --
> 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.