Alex Charalabidis <a...@wnm.net> writes:
> On 21 Jun 1999, Dag-Erling Smorgrav wrote:
> > The PR is wrong. Sheldon is right. It *does* work the way it ships. If
> > he experienced problems, I bet the real bug was that he edited
> > inetd.conf, HUPed inetd, and hit the "HUP clobbers the service table"
> > bug.
> I'll accept this as an explanation, since it sounds much more reasonable
> than telling me I have no clue what I'm talking about. I edit inetd.conf
> and HUP, like pretty much everyone else in the world and will keep HUPing
> for many years to come. If it "clobbers the service table" on the odd
> occasion and keeps it clobbered until you change the service's name, well
> duh, please document it, I'm not psychic. :)

We have no intention of documenting it, since the bug has been fixed.

>                                              If it also breaks on the
> first machine I install 3.2-R on and coincides with my discovery of
> aforementioned discrepancy, my guilt is limited to accepting an open
> invitation to jump to conclusions and I will redeem myself through a
> weekend penance of listening to the Spice Girls and watching Celine Dion.

We're not *that* mad at you. Just ten 'power to the world' and five
'Mmmm-bop' will do.

> > The alternative solution is to extend the format of inetd.conf to
> > allow specifying the service name after the 'internal' keyword, so you
> > could change /etc/services to read:
> Dare I suggest something as straightforward as bringing inetd, inetd.conf,
> /etc/services and the respective manpages into sync with each other and/or
> reality?

It's not the right solution. They'll only get out of sync again. The
correct solution is to stop pretending /etc/services means anything to
inetd except as a way to map service names to port numbers. It
doesn't, and never did.

DES
-- 
Dag-Erling Smorgrav - d...@flood.ping.uio.no


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to