The Name Service Cache Daemon (NSCD) is useful, but may get in your
way if you modify data that is cached and have the cache return stale
data until expiry.
One common scenario is an installation script that creates the
required user account, but first checks whether the account name
is currently unused. The query result (user does not exist) will
be cached by NSCD and will be returned even after the user has
been created in the password database (or in LDAP or whatever).
One solution is to signal changes of the database to NSCD, but
that requires an interfaces between the programs that modify
possibly cached data and NSCD.
A short timeout for negative query results is possible, but limits
the effectiveness of the cache. I propose a different solution,
which completely fixes the behavior in the scenario given above:
I have prepared a patch to NSCD that allows to specify a threshold for
negative queries. Requests for negative entries are only answered from
the cache after the specified number of attempts has been made to get
the result from the underlying files/databases.
A high number does effectively disable negative caching, but I doubt
that more than 3 is useful under normal conditions (this allows for
2 failures before the negative entry is trusted).
Rate limiting of queries with negative results continues to work with
this patch, since at most the specified number of retries is made within
the TTL of the cache entry.
A patch against -CURRENT is attached. It does not change the default
behavior in any way, so I think it would be save to commit to HEAD,
with possible MFC (since nothing changes unless you use the new
This patch has been tested with the hosts database and verified to work
as expected in my test cases.
To activate a negative query threshold you have to add lines like the
following to ncsd.conf::
negative-confidence-threshold hosts 3
negative-confidence-threshold passwd 2
negative-confidence-threshold group 2
A value of 2 will generally be sufficient. In the scenario where you
query the user DB to check that an account is free to use, there is
exactly one pro query with negative reply, before the user is added
and the query succeeds. A second probe would cache the negative reply.
Please let me know, whether it helps in situations with wrong
negative cacheing. I'm also interested in any problems you observe
with the patch. It would be great, if a native speaker had a look
at the patch for the man-page since I'm not convinced it is correct
and easy to understand.
And finally: Please suggest a better name for the parameter ...
I do not like "negative-confidence-threshold", but did not find any
PS: The patch contains an undocumented option to also set the
positive confidence threshold. Entries are put into the cache
but the original data sources are still queried, if the results
do not match for at least the number of successive queries
specified. Not sure whether this is useful, it was fall-out
of the negative threshold change ...
One possible use case is DNS based load-balancing. If NSCD
is configured with "positive-confidence-threshold hosts 3"
then it will require 3 identical replies for a host name
before it is willing to cache that reply. Any host with
fixed IP will soon be resolved from the cache, but hosts
with changing IP will continue to be queried via DNS (until
the specified number of identical results is received).
Hmmm, I'm not sure whether this works as advertised, since
any change in the returned data (including TTL) would cause
the counter to start over ...
PPS: I have not tested multipart queries; they should continue
to work as before (with a fixed threshold of 1). I have
not verified that this is the correct behavior, and have
run out of time for today ...