Greg Hudson writes:
> Before adopting complicated schemes like this, I strongly suggest that
> people consider whether /etc/nsswitch.conf is any different from other
> configuration files used by libc (such as /etc/resolv.conf) and whether
> all these extra considerations (do programs need to be restarted to pick
> up changes, are we concerned about programs losing while the file is
> being updated by an editor, do we need to compile the configuration file
> into a database file to speed up lookups) are necessary.

> I believe the conclusion you'll come to is that libc should parse the
> nsswitch.conf file at startup time and not make use of a db file.

Actually, I want to refute some of those claims:

- Solaris 2.x reads nsswitch.conf only on process startup. If you have
  a system or daemon that you can't shutdown, and you want to change
  the order of name service lookups, then you're in trouble. I've been
  using Solaris 2.x in various kinds of production environments for >2
  years now, and this fact peeves me. I'm not sure if the introduction
  of the nscd daemon fixes this in Solaris 2.5

- ULTRIX stats the file at each lookup. Very rarely I've seen programs
  temporarily complain that they can't find svc.conf because it's
  being updated by something else.

- nsswitch is something that will be called often, and should be fast.
  Adding this type of functionality and then telling users "by the
  way, this is going to slow things down" is not a way to keep people
  happy.

The code is written, it's working, and I suppose I should generate a
PR with the diffs. Then people can do what they want with it...

-- 
Luke Mewburn <luke.mewburn@itg.telstra.com.au>

Lawyers - the only group for which ignorance of the law is not a crime - anon