This one time, at band camp, Guido Guenther said: > Hi Stephen, > On Sun, May 27, 2007 at 03:01:48PM +0100, Stephen Gran wrote: > [..snip..] > > And this is the output: > > > > gid_t: 10110 starting > > gid_t: 10110 done > > gid_t: 10800 starting > > Enlarging buffer from 496 to 992 > > gid_t: 11197 starting > > gid_t: 11197 done > > > > Note that gid 10800 (the giant group) never shows done. > Yes there's a bug here, but I can't reproduce it (as you saw from my > output). Just to be sure I checked etch and it works there too. What > backend are you using? Maybe the bug is lurking there? Maybe the backend > isn't returning ERANGE as it should?
That's entirely possible. > [..snip..] > > > /* The status is NSS_STATUS_TRYAGAIN and errno is ERANGE the > > > provided buffer is too small. In this case we should give > > > the user the possibility to enlarge the buffer and we should > > > not simply go on with the next service (even if the TRYAGAIN > > > action tells us so). */ > > > > I saw that, and what it says to me is that the only way to do this is to > > rewind to the top of the loop and try again with a larger buffer. > > Currently, the buffer is being resized for all subsequent getent calls, > > but not for the failed one. > > Hmm...I interpreted this (and the code) like: "in this case we _will_ > give the user the possibility ..." - isn't this why the loop breaks and > returns the NSS_TRY_AGAIN? Note the __nss_next isn't called in this > case. I'm quiet sure the backend is at fault, could you try to deliver > the "giant" group via the file backend? I'm quiet sure this works and in > this case this bug should be reassigned to libnss-<your-backend> - > probably ldap. Actually nss-pgsql, but yes, perhaps the problem is really there. It's interesting to note that both alioth (with nss-pgsql) and another system (the nss-ldap) both seem to suffer from this problem with nss-updatedb, though. It is entirely possible that both nss implementations don't set errno to ERANGE, and this would explain it. It seems odd, but not impossible. I'll take another look at nss-pgsql and let you know - if I can force it to set errno to ERANGE, and it continues to break, then the problem is with updatedb. If it doesn't return ERANGE, then the problem is with the backend. Thanks, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : [EMAIL PROTECTED] | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
signature.asc
Description: Digital signature
