Bug 1923034

Summary: nscd -g does not report statistics as appropriate
Product: Red Hat Enterprise Linux 8 Reporter: Nicolas Chauvet (kwizart) <kwizart>
Component: glibcAssignee: glibc team <glibc-bugzilla>
Status: CLOSED UPSTREAM QA Contact: qe-baseos-tools-bugs
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.3CC: ashankar, codonell, dj, fweimer, mnewsome, pfrankli, sipoyare
Target Milestone: rc   
Target Release: 8.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-02-01 10:28:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Nicolas Chauvet (kwizart) 2021-02-01 10:26:05 UTC
Description of problem:
When using nscd to cache dns requests, the report created by "nscd -g" isn't accurate. All requests are added in the "cache miss" despite tests show some requests have been cached as appropriate.

Version-Release number of selected component (if applicable):
nscd-2.28-127.el8

How reproducible:
always

Steps to Reproduce:
1. dnf install nscd
2. systemctl enable nscd --now
3. 

Actual results:
All requests end in the "cache miss"

nscd -g:

 [...]
hosts cache:

            yes  cache is enabled
            yes  cache is persistent
            yes  cache is shared
            211  suggested size
         216064  total data pool size
            728  used data pool size
           3600  seconds time to live for positive entries
             20  seconds time to live for negative entries
              0  cache hits on positive entries
              0  cache hits on negative entries
              5  cache misses on positive entries
              2  cache misses on negative entries
              0% cache hit rate
              5  current number of cached values
              6  maximum number of cached values
              1  maximum chain length searched
              0  number of delays on rdlock
              0  number of delays on wrlock
              0  memory allocations failed
            yes  check /etc/hosts for changes

Expected results:
nscd from el7 works so at least some entries end in cache hit.

hosts cache:

            yes  cache is enabled
            yes  cache is persistent
            yes  cache is shared
            211  suggested size
         216064  total data pool size
           2224  used data pool size
           3600  seconds time to live for positive entries
             20  seconds time to live for negative entries
         141411  cache hits on positive entries
         113409  cache hits on negative entries
          48493  cache misses on positive entries
          39466  cache misses on negative entries
             74% cache hit rate
             15  current number of cached values
            375  maximum number of cached values
              7  maximum chain length searched
              1  number of delays on rdlock
              1  number of delays on wrlock
              0  memory allocations failed
            yes  check /etc/hosts for changes

 [...]

Additional info:
 # time getent hosts example.com
2606:2800:220:1:248:1893:25c8:1946 example.com

real    0m0,340s
user    0m0,000s
sys     0m0,002s
# time getent hosts example.com
2606:2800:220:1:248:1893:25c8:1946 example.com

real    0m0,002s
user    0m0,001s
sys     0m0,000s

Comment 1 Florian Weimer 2021-02-01 10:28:45 UTC
This is a design issue due to how the map-based cache works. The cache is read-only by design, so there is no way to communicate successful lookups to the cache from the client application to nscd.