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

David Wolfskill david at
Mon Aug 16 23:49:31 UTC 2010

On Sun, Aug 15, 2010 at 10:49:32PM -0700, David Wolfskill wrote:
> [...  rsyncd(8) port -- 873/tcp -- grabbed by either ypbind or amd before
>  rsynd started, so rsyncd isn't functional -- and doesn't whine about
>  it or terminate....]

Thanks for the suggestions so far.  Unfortunately, I'm finding an actual
solution rather elusive still.

Some poking around lead me to
<>, which chronicles
multipple instantiations of the same kind of problem over a period from
2003-08-29 16:13:45 EDT  - 2010-07-21 10:52:43 EDT [so far], with the
approach recommended for the RH crowd apparently being to make use of
portreserve (<>).

Unfortunately, doing that would seem to require modifying startup
scripts in the base system, as well, which seems to be a significant
barrier. [*]

* I haven't actually looked at the code, but from reading the comments
  in the above-cite bug report, the general idea is:
* portreserve is started early, and given a list of ports to reserve.
* A service that wants to use one of these "reserved" ports would have
  the start/stop scritp modified to invoke portrelease during start and
  (re-)invoke portreserve for stop.  Of course, this only handles
  controlled stops, and there could be a race condition....

As it was written for a Linux environment, I'm assuming(!) that the
license is not especially attractive for BSD.  But as noted above, base
system services would need to be modified to invoke it, which rather
plays havoc with the otherwise relatively clear distinction (in my mind,
anyhow) between "base" vs. "ports."

David H. Wolfskill				david at
Depriving a girl or boy of an opportunity for education is evil.

See for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url :

More information about the freebsd-ports mailing list