Wow, great observation: doing a "ls" of /etc/group and /etc/passwd fixes
it. How incredibly strange:

[root@XXXX svn]# chroot staging/db
id: cannot find name for group ID 0
id: cannot find name for group ID 1
id: cannot find name for group ID 2
id: cannot find name for group ID 3
id: cannot find name for group ID 4
id: cannot find name for group ID 6
id: cannot find name for group ID 10
I have no name!@XXXX:/# ls /etc/group /etc/passwd
/etc/group /etc/passwd
I have no name!@XXXX:/# exit
[root@XXXX svn]# chroot staging/db
root@XXXX:/#

Anyway, it's fantastic to have a workaround. Thanks a million!

Also, here's the output of "id" from a broken chroot; I don't actually
know if this fixes it -- I tried the "ls" trick and that did it, so I
don't know if "id" will fix it, too.

I have no name!@XXXX:/# id
uid=0 gid=0 groups=0,1,2,3,4,6,10

Finally, fixing one chroot neither fixes nor breaks the other -- they
seem entirely independent. (Great question, though.)

So, the next time I see it I'm going to see if "id" fixes it by itself.
I'm also going to read up more on the nscd and see if tweaking that
helps. It's a little slow going as it seems to take a long time for
this problem to re-appear; perhaps I can tweak nscd to force it to
happen more frequently, and thus better figure out how to make it not
happen it all.

Thanks for all your help!

-david


Daniel Burrows wrote:
> On Mon, Jun 30, 2008 at 01:12:34PM -0700, David Barrett <dbarrett@quinthar.com> was heard to say:
>> Basically, I go into staging/www, and it works fine. Then I go into
>> staging/db, and it has the problem. I immediately check the group
>> permissions, and note that now group IDs are being resolved to group
>> names, but user IDs aren't getting resolved. I then check the passwd
>> permissions, and note that both user and group names are now working. I
>> go right back to the group file, and now group and usernames are working
>> fine. I exit the broken DB chroot, and re-enter just fine.
>
> Just out of curiosity, does the chroot that *was* working continue to
> work after this?
>
> If you run, e.g., "id" a few times when it's broken, does it continue
> to be broken? And although I can't imagine why this would be the case,
> does the problem consistently go away for, e.g., passwords after you
> "ls" the password file? I notice that this happened in both of your
> last two examples: your problems with each file went away as soon as you
> listed it. Is there anything unusual about how your filesystems are
> configured?
>
>> As for nsswitch.conf, here it is: I haven't changed it, but I'm not
>> familiar with the file so I don't know if it's right or not:
>
> That looks right. The main concern would be if you had done something
> like fetching user information from LDAP, which would be another place
> for bugs to hide.
>
>> As for nscd... Aha! This is a good candidate: it turns out I *do* have
>> this installed on the host system. I don't know anything about this;
>> I'll need to read up on it.
>
> nscd caches lookups of things like uid <-> name mappings. I've had
> various problems in the past, which I won't detail because I can't
> remember them in detail, and I wouldn't recommend installing it unless
> you need to (mostly if you're using something like NIS or LDAP). This
> looks like the sort of gremlin that nscd could cause.
>
> However, I don't think I needed to ask whether you had it installed on
> the host system: it looks like it communicates via a Unix-domain socket
> in /var, so it wouldn't be able to interfere with what's happening in
> the chroots.
>
>
> I think an strace of a failing command (e.g., "id") would be very
> interesting.
>
> Daniel
>
>


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org