Date: Mon, 16 Aug 2010 16:07:50 +0530 From: Jyoti Sharma <jyoti.mickey@gmail.com> To: David Wolfskill <david@catwhisker.org> Cc: freebsd-ports@freebsd.org Subject: Re: It's annoying when something other than rsyncd listens on tco/873 Message-ID: <AANLkTikMGp1HxogA2c2zsX5Rdc9L62if_X9MQVmBVS65@mail.gmail.com> In-Reply-To: <20100816054932.GD1553@albert.catwhisker.org> References: <20100816054932.GD1553@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 mirro= r > 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. =A0Eventually, I discovered that the reason > was that amd(8) [on the build machine] was listening on 873/tcp, which > is the port for rsync. =A0I 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: =A0securelevel > # KEYWORD: shutdown > > and both amd & ypbind specify > > # BEFORE: =A0DAEMON > > 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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0david@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikMGp1HxogA2c2zsX5Rdc9L62if_X9MQVmBVS65>