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