This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Speeding up nscd


On Wed, Dec 26, 2012 at 11:31:54AM +0100, Ondřej Bílka wrote:
> This won't work for security reasons. Any user could modify cache to
> redirect everybody's traffic to evil.com.
> 
> However it could be possible for nscd to export its cache as read-only 
> mmaped file to avoid context switches on cached entries. 

This is what is already done; file descriptors of the respective map
files are passed on the nscd socket.

In the nscd/ directory, generally the nscd_* files are client code
included in glibc, and the rest is part of the nscd daemon. (Somewhat
confusingly...)

> Then another question is how persudate distributions to use nscd. Debian
> description is:
>  A daemon which handles passwd, group and host lookups
>  for running programs and caches the results for the next
>  query. You should install this package only if you use
>  slow Services like LDAP, NIS or NIS+

nscd has a bad reputation due to a fairly long history of bugs;
this stems from ugly spaghetti code and very aggressive use of
multi-threading coupled with some synchronization issues in sensitive
areas like garbage collection. Add NSS modules running in environment
not tested commonly (long-lived many-threaded applications) to the list
and as a result you get a list of bugs that not many are willing to
debug to the bone (especially if not paid for it).

I think that by now, pretty much all the common nscd bugs might be
ironed out, but its bad reputation lingers; I would expect it to be
the main reason why most distributions shied away from nscd. There is
also a "unscd" alternative that has its pros and cons.

Anyway, regarding the resolver issues, any solution must also work
without nscd, which is an optional system component. If all applications
(that do more than a single getaddrinfo() call during their runtime)
must implement similar logic of explicitly calling res_init() on some
event, forcing them to do it explicitly instead of just moving that
logic to glibc seems silly to me; I haven't thought about the topic
sufficiently to comment further, though.

-- 
				Petr "Pasky" Baudis
	For every complex problem there is an answer that is clear,
	simple, and wrong.  -- H. L. Mencken


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]