Am 19.09.26 um 23:40 schrieb Vincent Lefevre:
On 2026-09-19 20:41:06 +0200, Marco Moock wrote:
Am 18.09.26 um 14:30 schrieb Vincent Lefevre:
On 2026-09-17 10:22:24 +0700, Max Nikulin wrote:
My point is that, reporting a bug, you should avoid non-essential steps to
reproduce it. More generic configuration that is closer to defaults means
that the scope of the issue is wider. It require less efforts to try and to
create debug environment. In this thread you see that mention of disabled
IPv6 may insult people. Reaction of developers might be similar.
"mention of disabled IPv6 may insult people"???
No, but it is a rather uncommon situation.
What is actually uncommon is a network with unsupported IPv6
and DNS servers that often return SERVFAIL.
IPv6 being disabled in the kernel is rather uncommon.
In any case, I don't see why IPv6 support in the kernel matters
for nscd. I don't see any reason why nscd would do an IPv6
connection; that's useless for name resolving.
nscd is only a cache for libc, it does not do any lookups. The sources
defined in nsswitch.conf do the lookups.
If you have specific questions about nscd on Linux, see
https://sourceware.org/mailman/listinfo
nscd is part of glibc.
Then you cannot reasonably open a bug report - because the developers will
ask you to do such test. Set up a test environment (e.g. Virtualbox) and
track the issue down.
Developers could (should) do their own tests: testing the behavior
of nscd with an initial SERVFAIL for IPv4 and a valid IPv6 address
(or the reverse).
SERVFAIL is an error message of unicast DNS. nscd is not involved in
that part, this is done by libnss_resolve by default - or
systemd-resolved (with libnss-resolve).
If handling of that itself is faulty, those libraries need to be checked.
I was not aware of how nscd worked at the time of the bug report.
The nscd(8) man page is ridiculously uninformative. Developers
should do their work first.
It is simply a cache for requests using the libc functions. Be aware that
the libc stuff is different in Linux/BSD/UNIX, so you may find information
that does not apply to the Linux implementation.
I was just asking for the cache specification for nscd.
I do not have one, maybe as on the lists at sourceware.
BTW, I've just found that the French (and much older) version is much
more informative: http://manpagesfr.free.fr/man/man8/nscd.8.html
That doesn't say from which distribution it came (at
I suppose that this corresponds to upstream.
Or does the nscd(8) man page depend on the distribution?
The implementation depends. GNU (used on Linux), BSD and Solaris exist
(maybe more for other commercial UNIX) and are different regarding their
settings and behavior.
TLDR: You might find information about nscd that does not apply to the
libc implementation that you are using.
When possible, use standard tools like getent instead of custom
programs or scripts.
getent does *not* work in the same way. In particular, in the test,
I got an exit status 2 in each case while IP addresses were available
in each case (e.g. with getaddrinfo). And no error messages at all.
That's very unhelpful.
Can you give a test case?
Already given, with results, in <[email protected]>
(Sun, 13 Sep 2026 02:35:49 +0200). This is:
#!/bin/sh
getent ahostsv4 $1 || echo "Error: $?"
getent ahostsv6 $1 || echo "Error: $?"
getent ahosts $1 || echo "Error: $?"
I tried that on my machine with google.com as argument, works fine.
$ grep hosts /etc/nsswitch.conf
hosts: files dns
nscd is enabled and working (I searched the cache with the strings command).
--
Gruß
Marco
Spam bitte an [email protected]
