Jacques A. Vidrine schrieb am 2004-10-08: > > All that is needed is that interfaces that cannot communicate a > > temporary failure and do not fail when used without NIS (such as > > getpw*()) retry forever until they can offer a permanent result. > > Though your PR may have merit, this is not a "showstopper bug" for > 5.3. FreeBSD has this behavior since the dawn of time, as does Linux > (IIRC). About time this was fixed then after such a long period of falsely claiming that existing users were nonexistent within periods of NIS/network trouble. Linux's (GNU libc's, to be precise) current behaviour is nothing more than a poor and incomplete copy of Solaris' "name service switch" interface - Linux lacks TRYAGAIN=forever functionality with is the default on Solaris for anything but DNS (and the DNS-related interfaces such as gethostbyname DO have a means to distinguish temporary from permanent error). The problem is that the current code, in case of a temporary problem, pretends that there was a permanent condition, and this must end, very few applications (if any) check for errno. Convenience link: http://www.freebsd.org/cgi/man.cgi?query=nsswitch.conf&apropos=0&sektion=0&manpath=SunOS+5.8&format=html What _technical_ reason is there that prevents a fix? (don't tell me we've been doing this for so long or WackOS XYZ has been doing this for so long). Currently, FreeBSD's NIS implementation is a fair weather implementation. The issue at hand is also found to be annoying and reported by other people, see for instance Rahul Dhesi's post to the GNU libc bug report list: http://www.mail-archive.com/bug-glibc_at_gnu.org/msg07471.html http://sources.redhat.com/bugzilla/show_bug.cgi?id=430 I have recently been burnt _again_ by this issue and I am more than annoyed. If all that is missing is someone who hacks libc, I'll try my best but I have little experience with RPC so I'm not sure if I can come up with something quickly. Cheers, -- Matthias Andree Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)Received on Sat Oct 09 2004 - 09:05:06 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:16 UTC