Re: bringing /etc/services up to date

On Wed, Jul 07, 2004 at 01:13:27PM -0500, Matthew D. Fuller wrote:
> On Wed, Jul 07, 2004 at 10:25:58AM -0700 I heard the voice of
> Brooks Davis, and lo! it spake thus:
> > 
> > Can you check how much this change slows down inetd startup with a
> > few services enabled?  The traditional argument against this is that
> > reading the whole IANA service file takes too long.  If the
> > difference isn't measurable, the the argument is bogus, but I'm not
> > sure that's the case.  The alternative solution would be to add
> > optional database backing.  That shouldn't be too hard to do, and
> > there are several examples to work from.
> 
> In theory, any program reading the data should be using
> getservby{name,port}() and friends, since it avoids code duplication
> and handles NIS and such already.  So, hashing it into a DB and fixing
> those functions to match would probably work.  When this has been
> brought up in the past, there's been expressed concern that a number
> of programs don't, and piddle with the file manually, so while they
> could still read the flatfile, they'd be in the dumps on performance
> as the file grew.  AFAIK, nobody's even done any exhaustive testing of
> whether that really happens, or how much gain hashing would give.

IMO, programs that read the flatfile will get what they deserve.  They
are broken and can not work in perfectly valid environments.  For
instance, they won't work with the following services file in an NIS
environment:

sunrpc          111/tcp    rpcbind      #SUN Remote Procedure Call
sunrpc          111/udp    rpcbind      #SUN Remote Procedure Call
syslog		514/udp
+

-- Broooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4