Vincent, are you interested in improving your bug report? Otherwise we
may stop the discussion. I am just rather skeptical if current
description may attract attention of the developers. My impression is
that reporting bugs is not infrequent activity for you.
On 18/09/2026 7:14 pm, Vincent Lefevre wrote:
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"???
Isn't significant part of this thread is dedicated to arguments that you
should not disable IPv6? Some messages were harsh enough in my opinion.
Others may suspect that you broke your system in attempts to disable
IPv6. Enough efforts have been invested into making default
configuration working out of the box when IPv6 is enabled, but global
routing is not available. Do you want to waste time for similar side
tracks in comments to the bug report?
Since error messages are different, it is better to describe primary
scenario with default IPv6 configuration (local addresses, no global
routing).
I could not try. That's not my fault if non-root users cannot test
(emulate) such a configuration.
I had impression that you had access to another machine with IPv6
enabled. Alternatively VMs may be used for debugging without root
permissions on the host system.
By the way, the current description does not mention that IPv6 is
unavailable, so impact is unclear. It may be assumed that any tool may
successfully connect to hosts using their IPv6 address without any
noticeable effect.
Actual impact is rather severe namely when IPv6 global routing is
absent. It is close to complete disaster when significant part of DNS
queries fail. In the case of rare errors, it is hard to figure out what
actually goes wrong and the result is impression of nscd as a broken
tool. (Is it the reason why an alternative implementation was created?)
Your bug report lacks timestamps that proof that partial failure is treated
as success while the setting to quickly expunge negative results from the
cache is respected.
I was not aware of how nscd worked at the time of the bug report.
The question is whether the report can be made more clear now.
The nscd(8) man page is ridiculously uninformative. Developers
should do their work first.
Assume that developers are busy or overloaded with other bugs, features,
and discussions. Likely they receive tons of notifications, so your bug
will be ignored if it is unclear or in the case if any doubts concerning
its impact.
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
I agree. You may try to play "git log" game to figure out whether the
addition was specific to French variant or it existed in the original
page as well.
nscd.conf(5) does not have an overview as well, but option names may
give some hints.
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.
I have noticed that "--help" output contains an option missed in the man
page, but might help during debug
-A, --no-addrconfig
do not filter out unsupported IPv4/IPv6 addresses (with ahosts*)
Perhaps someone should write a debugging program that prints all the
needed information for bug reports, and distribute it in standard.
At first, it is necessary to figure out what features are necessary.
Your tool does not allow to change order of queries to check if
AF_UNSPEC and AF_INET caches affect each other.
