table of contents
nscd.conf(5) | File Formats Manual | nscd.conf(5) |
NAME¶
nscd.conf - name service cache daemon configuration file
DESCRIPTION¶
The file /etc/nscd.conf is read from nscd(8) at startup. Each line specifies either an attribute and a value, or an attribute, service, and a value. Fields are separated either by SPACE or TAB characters. A '#' (number sign) indicates the beginning of a comment; following characters, up to the end of the line, are not interpreted by nscd.
Valid services are passwd, group, hosts, services, or netgroup.
logfile debug-file-name
debug-level value
threads number
max-threads number
server-user user
stat-user user
reload-count unlimited | number
paranoia <yes|no>
restart-interval time
enable-cache service <yes|no>
positive-time-to-live service value
negative-time-to-live service value
suggested-size service value
check-files service <yes|no>
persistent service <yes|no>
shared service <yes|no>
max-db-size service bytes
auto-propagate service <yes|no>
NOTES¶
The default values stated in this manual page originate from the source code of nscd(8) and are used if not overridden in the configuration file. The default values used in the configuration file of your distribution might differ.
Reloading¶
nscd(8) has a feature called reloading, whose behavior can be surprising.
Reloading is enabled when the reload-count attribute has a non-zero value. The default value in the source code enables reloading, although your distribution may differ.
When reloading is enabled, positive cached entries (the results of successful queries) do not simply expire when their TTL is up. Instead, at the expiry time, nscd will "reload", i.e., re-issue to the name service the same query that created the cached entry, to get a new value to cache. Depending on /etc/nsswitch.conf this may mean that a DNS, LDAP, or NIS request is made. If the new query is successful, reloading will repeat when the new value would expire, until reload-count reloads have happened for the entry, and only then will it actually be removed from the cache. A request from a client which hits the entry will reset the reload counter on the entry. Purging the cache using nscd -i overrides the reload logic and removes the entry.
Reloading has the effect of extending cache entry TTLs without compromising on cache coherency, at the cost of additional load on the backing name service. Whether this is a good idea on your system depends on details of your applications' behavior, your name service, and the effective TTL values of your cache entries. Note that for some name services (for example, DNS), the effective TTL is the value returned from the name service and not the value of the positive-time-to-live attribute.
Please consider the following advice carefully:
- •
- If your application will make a second request for the same name, after more than 1 TTL but before reload-count TTLs, and is sensitive to the latency of a cache miss, then reloading may be a good idea for you.
- •
- If your name service is configured to return very short TTLs, and your applications only make requests rarely under normal circumstances, then reloading may result in additional load on your backing name service without any benefit to applications, which is probably a bad idea for you.
- •
- If your name service capacity is limited, reloading may have the surprising effect of increasing load on your name service instead of reducing it, and may be a bad idea for you.
- •
- Setting reload-count to unlimited is almost never a good idea, as it will result in a cache that never expires entries and puts never-ending additional load on the backing name service.
Some distributions have an init script for nscd(8) with a reload command which uses nscd -i to purge the cache. That use of the word "reload" is entirely different from the "reloading" described here.
SEE ALSO¶
2024-05-02 | Linux man-pages (unreleased) |