On 2026-09-20 00:11:22 +0700, Max Nikulin wrote: > Vincent, are you interested in improving your bug report?
Yes, but note that I have a very limited time. > 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. Yes, and I have other bug reports to work on in my todo list. > 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? No-one has explained why IPv6 should not be disabled. And in any case, if this is allowed by the kernel, this should not have any effect. And the nscd documentation does not say that IPv6 should not be disabled in the kernel (and I do not see why this would matter since name resolution is unrelated to IPv6 support). > Some messages were harsh enough in my opinion. > Others may suspect that you broke your system in attempts to disable IPv6. Please explain how this can break the system. > > > 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. The machines where I am not root have IPv6 disabled. Still on the ENS-Lyon network, I have 2 personal machines with IPv6 enabled. Currently I mostly use them remotely because it is too hot in my lab office, and I need to be physically present in front of the machine if I try to change the network settings for testing. > By the way, the current description does not mention that IPv6 is > unavailable, so impact is unclear. True, I forgot to add that (note this has an effect only on the impact; this would still be an unexpected behavior with IPv6 available). I should also add that some programs use getaddrinfo with AF_UNSPEC *only* (otherwise the bug would not have any effect, because AF_INET gives the IPv4 address as expected). But note that if I complain about the missing IPv4 address, this means that there is normally a practical reason. > > 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*) This is unrelated anyway, and the behavior is strange: on a machine with IPv6 disabled: citron:~> getent ahostsv6 joooj.vinc17.net || echo $? 2 citron:~> getent -A ahostsv6 joooj.vinc17.net || echo $? ::ffff:155.133.131.76 STREAM joooj.vinc17.net ::ffff:155.133.131.76 DGRAM ::ffff:155.133.131.76 RAW but citron:~> getent ahosts joooj.vinc17.net || echo $? 155.133.131.76 STREAM joooj.vinc17.net 155.133.131.76 DGRAM 155.133.131.76 RAW citron:~> getent -A ahosts joooj.vinc17.net || echo $? 155.133.131.76 STREAM joooj.vinc17.net 155.133.131.76 DGRAM 155.133.131.76 RAW > > 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. I don't think they do (at least with nscd running), because when I ran my gai tool again, I was getting the same results. -- Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
