Bug 1923034 - nscd -g does not report statistics as appropriate
Summary: nscd -g does not report statistics as appropriate
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: glibc
Version: 8.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: glibc team
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-01 10:26 UTC by Nicolas Chauvet (kwizart)
Modified: 2023-07-18 14:30 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-01 10:28:45 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Sourceware 16104 0 P2 NEW nscd statistics are inaccurate when local client searches cache. 2022-10-28 13:11:31 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.