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 <[email protected]> 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 [email protected] > Depriving a girl or boy of an opportunity for education is evil. > > See http://www.catwhisker.org/~david/publickey.gpg for my public key. _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
