Date: Tue, 17 Oct 2006 10:19:12 -0500 From: Brooks Davis <brooks@one-eyed-alien.net> To: Trond Endrest?l <Trond.Endrestol@fagskolen.gjovik.no> Cc: re@freebsd.org, FreeBSD stable <freebsd-stable@freebsd.org> Subject: Re: Ensuring inetd is started before any RPC services Message-ID: <20061017151911.GC68977@lor.one-eyed-alien.net> In-Reply-To: <20061017171137.W27675@ramstind.fig.ol.no> References: <20061017082319.I27675@ramstind.fig.ol.no> <20061017143947.GA68977@lor.one-eyed-alien.net> <20061017171137.W27675@ramstind.fig.ol.no>
next in thread | previous in thread | raw e-mail | index | archive | help
--6zdv2QT/q3FMhpsV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 17, 2006 at 05:14:22PM +0200, Trond Endrest?l wrote: > On Tue, 17 Oct 2006 09:39-0500, Brooks Davis wrote: >=20 > > On Tue, Oct 17, 2006 at 08:46:49AM +0200, Trond Endrest?l wrote: > > > I have on many occasions run into the situation where the RPC based= =20 > > > services have occupied the well-known ports for other non-RPC based= =20 > > > services. Last week rpc.lockd on one of my systems got hold of TCP=20 > > > port 995, leaving inetd unable to start any pop3s services. > > >=20 > > > The easy cure is to add this line > > >=20 > > > # BEFORE: rpcbind > > >=20 > > > to /etc/rc.d/inetd. > > >=20 > > > You might want to consider fixing /etc/rc.d/inetd prior to the releas= e=20 > > > of 6.2. > >=20 > > I'm pretty sure this change would break inetd's rpc service support and > > would change the startup order more significantly than I think is > > appropriate this late in the release cycle. >=20 > Yes, I see your point. >=20 > I guess we who never run any RPC services through inetd must make this=20 > change ourself, and it's relatively easy to maintain this change when=20 > using mergemaster after each installworld. One size does not fit all,=20 > not in this case. It's clear to me that we need a better way to specifying which ports services that want an arbitrary port can use. That's probably the long term solution. -- Brooks --6zdv2QT/q3FMhpsV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFNPRvXY6L6fI4GtQRAkXmAKC1TrvMkYM4TEeA38XnmboW54SOtQCeMRZ+ 3kGQCbF0LufjG/7Dt2i2ufg= =eafy -----END PGP SIGNATURE----- --6zdv2QT/q3FMhpsV--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061017151911.GC68977>